Enable-ClusterS2D stuck at 59% + Cluster Validation WMI error Msvm_ComputerSystem

Question

Enable-ClusterS2D stuck at 59% + Cluster Validation WMI error Msvm_ComputerSystem

Lucas Thimonier 0

Hello everyone,

I’m currently deploying a two-node Hyper-V cluster with Storage Spaces Direct (S2D) on Windows Server Datacenter 2025. One specific aspect is that this infrastructure has no connectivity to the outside world. Both servers are Dell PowerEdge R760xs (same generation / same configuration) and are dedicated to virtualization. I followed Microsoft recommendations for implementing a Hyper-V + S2D cluster, and for the networking part I relied on the Lenovo “Microsoft Storage Spaces Direct (S2D) Deployment Guide”.

From a hardware perspective, each node has identical resources (CPU/RAM) and local storage intended for S2D. The setup is standard: the Dell PERC H355 adapter is used only for the system disk and server cache and is not intended to be part of the S2D pool. The disks planned for S2D are presented in a way that meets S2D requirements (not in RAID, and visible to the OS so they can be pooled by Storage Spaces Direct).

The issue is that when running Enable-Cluster, the process gets stuck at 59% and does not progress any further. It hangs specifically at the “Check Health” step. In addition, during cluster validation I get an error on a Hyper-V/WMI-related test stating that it cannot find an Msvm_ComputerSystem instance. This is surprising because the WMI checks I performed between the two nodes work properly: I can query the Msvm_ComputerSystem class remotely using Get-CimInstance without any error.

If anyone has already encountered Enable-ClusterS2D freezing at 59% on “Check Health”, or cluster validation failing on Msvm_ComputerSystem in a similar context, I would really appreciate any feedback and practical troubleshooting pointers: which logs should be checked first (Cluster/S2D/Hyper-V), what typical checks/services can block the “Check Health” step, and which configuration items most commonly cause this behavior in a two-node deployment.

Environment: Windows Server 2025 Datacenter Edition

Installed roles/features: Hyper-V, Failover Clustering, DCB, Files and Storage Services

Architecture: 2-node cluster, RoCE (RDMA), direct-connected between the two nodes

Server model: Dell PowerEdge R760xs CPU: Intel Xeon Gold 6426Y (16 cores / 32 threads)

Memory: RDIMM 5600 MT/s (capacity can be provided if needed)

Storage controller: PERC H355 Adapter (Customer Kit)

OS disks: RAID 1 — 480 GB SATA SSD, 6 Gbit/s,

S2D disks: 1.2 TB SAS ISE disks, 12 Gbit/s

Network CorpNet : 2 × 10/25 GbE SFP28 (SET-based virtual switch)

RDMA network: 2 × 100 GbE QSFP56 (RDMA, RoCE, direct link between nodes)

Thanks in advance for your help.

0 commentaires

1 réponse

Votre réponse

Answer 1

Bonjour Lucas Thimonier,

Le comportement que vous observez indique généralement une incohérence dans l’enregistrement du fournisseur WMI Hyper-V ou dans les dépendances des services de cluster. Même si les requêtes WMI manuelles aboutissent, le processus de validation du cluster repose sur le fait que certains services Hyper-V spécifiques soient entièrement initialisés et correctement enregistrés. Cela peut échouer si l’hôte ne dispose pas de connectivité externe ou si certaines mises à jour sont manquantes.

Je vous recommande de vérifier les journaux FailoverClustering-Manager et Hyper-V-VMMS dans l’Observateur d’événements afin d’identifier d’éventuelles erreurs au moment de la validation. Vérifiez également que le service de gestion des machines virtuelles Hyper-V (Hyper-V Virtual Machine Management Service – vmms.exe) est bien en cours d’exécution et que la configuration DCB/RDMA est cohérente sur les deux nœuds. Dans les déploiements à deux nœuds, il est particulièrement important de valider les paramètres de quorum et de s’assurer que le témoin de cluster est correctement configuré, même dans des environnements isolés.

Si le problème persiste, essayez de réenregistrer le fournisseur WMI Hyper-V à l’aide de la commande mofcomp %systemroot%\system32\wbem\vmms.mof*, puis relancez la validation du cluster. Cela permet souvent de résoudre l’erreur liée à l’absence de l’instance Msvm_ComputerSystem.

J’espère que cela vous aidera. Si ces indications vous permettent d’avancer, merci de cliquer sur « Accept Answer » afin que je sache que votre problème est résolu 😊. Si vous avez besoin d’aide supplémentaire, n’hésitez pas à laisser un commentaire.

Jason.