Après chaque redémarrage, votre hôte Hyper‑V 2022 perd une VM stockée sur iSCSI et l’état « Off‑Critical » s’affiche ? Voici le diagnostic, la cause profonde et une procédure pas‑à‑pas pour corriger définitivement avec un Cluster Shared Volume (CSV) et un cluster de basculement.
Contexte et symptômes observés
Un hôte Hyper‑V 2022 (serveur #2) connecté à un NAS tout‑flash via iSCSI perdait systématiquement sa seule machine virtuelle après chaque redémarrage.
- Au boot, la VM apparaissait dans Hyper‑V avec l’état Off‑Critical.
- Les trois fichiers de configuration
.vmcxet.vmrsrestaient présents, mais le disque virtuel VHDX avait « disparu » du volume iSCSI (monté commeD:). - Redémarrer les services Hyper‑V, reset la session iSCSI ou rescanner les disques ne changeait rien ; la VM restait inopérante.
Ce que signifie vraiment « Off‑Critical »
Dans Hyper‑V, Off‑Critical indique qu’une machine virtuelle est arrêtée mais dans un état d’erreur critique parce qu’une ressource indispensable manque. Le cas le plus courant : un VHDX introuvable ou un chemin de stockage inaccessible au moment où le service Hyper‑V tente de réattacher le disque. Autrement dit, la configuration de la VM existe, mais le stockage référencé est absent, verrouillé, ou indisponible.
Diagnostic : la cause profonde
Le LUN iSCSI était présenté en multi‑connect aux deux hôtes Hyper‑V, mais il n’était pas intégré à un cluster de basculement et n’avait pas été converti en CSV. Résultat :
- Chaque hôte voyait le même LUN formaté en NTFS comme s’il en était le propriétaire, ce qui est interdit hors cluster (risque de corruption).
- Pour se protéger, Windows peut mettre le disque en Offline sur l’un des hôtes ou empêcher son montage, rendant le VHDX invisibile sur ce serveur au redémarrage.
- Au démarrage de Hyper‑V, la VM ne retrouve pas son VHDX ; l’état devient Off‑Critical.
En environnement cluster, le stockage partagé doit être contrôlé par le service de cluster et exposé à Hyper‑V via Cluster Shared Volumes (CSV). Le CSV fournit une couche d’orchestration (réservations SCSI‑3, arbitrage, chemins d’accès uniformes via C:\ClusterStorage\VolumeX) qui garantit que les deux hôtes voient un même volume en lecture/écriture, de manière sûre et simultanée.
Solution adoptée
- Créer/compléter le cluster de basculement entre les deux hôtes Hyper‑V.
- Ajouter le LUN iSCSI au cluster (ressource « Disque cluster ») puis Convertir en CSV.
- Déplacer/référencer la VM dans
C:\ClusterStorage\VolumeX\VMset faire gérer la VM par le cluster (Rôle « Machine virtuelle »).
Après conversion, le volume apparaît sous C:\ClusterStorage\VolumeX sur tous les nœuds ; la VM reste intacte après redémarrage et peut basculer d’un hôte à l’autre sans interruption planifiée.
Procédure pas‑à‑pas (PowerShell et GUI)
Pré‑requis côté hôtes
- Windows Server 2022 à jour (mises à jour cumulatives, pilotes NIC, HBA, firmware BIOS/UEFI).
- Rôles et fonctionnalités : Hyper‑V, Failover‑Clustering, Multipath‑IO (MPIO).
- Deux interfaces iSCSI par hôte (ou plus) sur un réseau dédié iSCSI (VLAN/VRF séparés, QoS le cas échéant).
- LUN iSCSI sur le NAS avec SCSI‑3 Persistent Reservations et chemins multiples (ALUA si disponible).
Installation des fonctionnalités
# Sur chaque hôte
Install-WindowsFeature -Name Hyper-V, Failover-Clustering, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Multipath-IO -IncludeManagementTools
# Activer et démarrer l’initiateur iSCSI
Set-Service -Name MSiSCSI -StartupType Automatic
Start-Service -Name MSiSCSI
# MPIO (DSM Microsoft) – peut nécessiter un redémarrage
mpclaim -r -i -a Remarque : mpclaim -r -i -a réclame les périphériques pour le DSM Microsoft et planifie un redémarrage. Exécutez‑le dans une fenêtre élevée.
Connexion aux cibles iSCSI
Via l’interface « Initiateur iSCSI » (iscsicpl) :
- Ajouter les portails cibles (adresses IP iSCSI du NAS).
- Découvrir la cible et connecter avec multi‑chemins (cocher « Activer MPIO », ouvrir une session par NIC).
- Vérifier que chaque LUN apparaît une seule fois au niveau OS (MPIO agrège les chemins).
Création/validation du cluster
# Valider l’infrastructure (réseau, stockage, inventaire)
Test-Cluster -Node "HV1","HV2" -Include "Storage","Inventory","Network" | Out-File C:\Temp\ValidationCluster.txt
# Créer le cluster (sans ajouter le disque pour l’instant)
New-Cluster -Name "HV-Cluster" -Node "HV1","HV2" -StaticAddress 10.10.10.100 -NoStorage
# Configurer un témoin (File Share Witness ou Cloud Witness, recommandé pour 2 nœuds)
# Ex. : Set-ClusterQuorum -FileShareWitness \fsw\ClusterWitness
Ajouter le LUN au cluster et convertir en CSV
# Lister les disques disponibles et les ajouter au cluster
Get-ClusterAvailableDisk | Add-ClusterDisk
# Convertir le disque cluster en CSV
$disk = Get-ClusterResource | Where-Object { $_.ResourceType -eq "Physical Disk" } | Select-Object -First 1
$disk | Add-ClusterSharedVolume
# Vérifier les CSV et récupérer le chemin monté
Get-ClusterSharedVolume | Format-Table Name, State, OwnerNode
# Afficher le chemin Friendly (ex. C:\ClusterStorage\Volume1)
(Get-ClusterSharedVolume)[0].SharedVolumeInfo.FriendlyVolumeName Déplacer les VMs et les mettre sous contrôle cluster
- Arrêter proprement la VM.
- Déplacer VHDX et fichiers de configuration vers
C:\ClusterStorage\VolumeX\VMs\<NomVM>. - Dans le Gestionnaire du cluster de basculement : Configurer un rôle > Machine virtuelle > Importer une VM existante et pointer sur le nouveau chemin CSV.
- Vérifier la chaîne de dépendances : la ressource « Machine virtuelle <Nom> » doit dépendre de « Configuration de la machine virtuelle <Nom> », qui dépend du CSV. Le cluster orchestre alors l’ordre de démarrage.
Mesures correctives et bonnes pratiques
| Étape | Objectif | Détails utiles |
|---|---|---|
| Valider l’infrastructure | Garantir la compatibilité cluster | Exécuter l’analyse de validation de cluster (Test-Cluster) entre les hôtes ; vérifier PR SCSI‑3, chemins MPIO, et latence réseau. |
| Ajouter le LUN au cluster | Partage sécurisé du stockage | Dans le Gestionnaire de cluster, Ajouter un disque > Disque cluster, puis Ajouter au CSV. Le volume devient accessible via C:\ClusterStorage\VolumeX. |
| Migrer/placer les VMs | Stockage haute disponibilité | Stocker VHDX & fichiers de conf dans \ClusterStorage\VolumeX\VMs. Les chemins restent stables quel que soit le nœud propriétaire. |
| Configurer MPIO | Chemins redondants iSCSI | Activer MPIO (DSM Microsoft) ; définir la politique (ex. Least Queue Depth ou selon le constructeur) et vérifier la bascule de lien. |
| Ordre de démarrage | Assurer la montée du stockage | Le service Initiateur iSCSI en Automatique. Dans le cluster, vérifier les dépendances VM → CSV et l’AutoStart des rôles. |
| Sécurité & firmware | Limiter les pannes | Mises à jour NIC & NAS ; segmentation réseau iSCSI (pas d’interruption par tempêtes broadcast) ; pas d’antivirus temps réel sur C:\ClusterStorage. |
| Sauvegarde et tests | Prévenir la corruption | Exporter des copies à froid des VHDX ; tester régulièrement Live Migration et Failover planifiés. |
Points de vigilance supplémentaires
- Réseau iSCSI : une latence variable ou la perte de paquets déclenchent des bascules MPIO, des entrées/sorties redirigées sur CSV et, au pire, des déconnexions. Surveiller la qualité du lien 10 Gb/s (ou 25/40 Gb/s) et éviter les micro‑bursts non gérés.
- Snapshots NAS : s’ils sont planifiés, s’assurer qu’ils n’introduisent pas un montage en lecture seule ou un verrou sur le LUN au moment du redémarrage des hôtes.
- Licences : en cluster 2 nœuds sous Windows Server 2022, l’édition Standard suffit si seules 2 VM tournent simultanément par hôte ; au‑delà, prévoir Datacenter.
- Quorum : sur 2 nœuds, configurez un File Share Witness ou Cloud Witness pour éviter les suspensions de cluster au redémarrage d’un nœud.
- Jumbo Frames : n’activez que si toute la chaîne (NIC, switchs, NAS) est homogène et validée. Un MTU incohérent provoque des pertes subtiles.
- Antivirus : exclure
C:\ClusterStorageet les processus Hyper‑V (analyse en temps réel) pour éviter les verrous de fichiers VHDX.
Pourquoi le VHDX « disparaissait »
Le disque n’était pas vraiment supprimé. Sans CSV :
- Le LUN NTFS présenté à plusieurs hôtes provoque un conflit d’accès. Windows met généralement un des volumes en Offline pour protéger les métadonnées NTFS.
- Au redémarrage, l’hôte perd « D: » ou monte un autre volume à cette lettre ; la VM pointe alors vers un chemin invalide (
D:\VMs\…), d’où l’erreur. - Le cluster/CSV élimine ce problème en fournissant un chemin unique (
C:\ClusterStorage\VolumeX) et en gérant les réservations SCSI‑3 pour les accès concurrents.
Runbook express de remédiation
- Arrêter la VM affectée (si partiellement visible).
- Valider le cluster (
Test-Cluster) et corriger les erreurs bloquantes : PR SCSI‑3, multi‑chemins, latence. - Ajouter le disque au cluster, convertir en CSV.
- Déplacer VHDX et configuration dans
C:\ClusterStorage\VolumeX\VMs. - Importer la VM comme Rôle dans le cluster ; vérifier dépendances.
- Démarrer la VM et exécuter une Live Migration de test vers l’autre nœud.
Commandes utiles de vérification
# État CSV et propriétaire
Get-ClusterSharedVolume | Format-Table Name, State, OwnerNode
# Journal du cluster sur les dernières 5 minutes (utile après un redémarrage)
Get-ClusterLog -UseLocalTime -TimeSpan 5 -Destination C:\Temp
# Services essentiels
Get-Service vmms, clussvc, msiscsi | Format-Table Name, Status, StartType
# Chemins MPIO (résumé)
mpclaim -s -d
# Performances CSV (pointeurs)
# Utiliser Performance Monitor "Cluster CSV File System" : Redirected IO, Read/Write Latency, etc.
Architecture recommandée (vue d’ensemble)
- 2 × hôtes Hyper‑V en Windows Server 2022, rôle Failover Clustering activé.
- NAS/array iSCSI avec support SCSI‑3 PR, alimente un LUN (ou plusieurs) dédié(s) aux VMs.
- Réseau iSCSI dédié (2 liens par hôte, MPIO actif, VLAN isolé, QoS si nécessaire).
- CSV monté sous
C:\ClusterStorage\VolumeX; toutes les VMs stockées sous ce chemin. - Quorum : File Share/Cloud Witness.
Alternatives si vous ne voulez pas de cluster
- Un LUN par hôte : ne jamais présenter un même LUN NTFS à plusieurs hôtes si vous n’avez pas de cluster. Les VMs restent locales à chaque hôte ; pas de mobilité ni de HA.
- SMB 3 (SOFS) : stocker les VHDX sur un partage hautement disponible (Scale‑Out File Server). Hyper‑V gère nativement SMB 3 (RDMA possible).
- VHD Set / guest clustering : pour des applications clusterisées à l’intérieur des VMs (SQL FCI, etc.), mais ce n’est pas une alternative au cluster d’hôtes pour la haute disponibilité des VMs elles‑mêmes.
Checklist de durcissement
- ✔ Mises à jour OS, NIC, HBA, firmware NAS alignées et validées.
- ✔ MPIO installé ; politique de chemin conforme aux recommandations du constructeur de stockage.
- ✔ LUNs dédiés aux VMs (taille, alignement, blocs) ; pas de mélange avec d’autres charges.
- ✔ CSV activé ;
C:\ClusterStorage\VolumeXcomme unique chemin de stockage VM. - ✔ Quorum en place (witness) et « Valider le cluster » sans erreurs critiques.
- ✔ Sauvegardes cohérentes Hyper‑V (VSS) testées et restauration validée.
- ✔ Exclusions AV sur
C:\ClusterStorageet processus Hyper‑V. - ✔ Tests réguliers de Live Migration et basculement planifié.
Dépannage rapide si le problème revient
| Symptôme | Piste immédiate | Commande/Action |
|---|---|---|
| VM en Off‑Critical | Chemin VHDX invalide | Vérifier que le chemin pointe vers C:\ClusterStorage\... et que le CSV est Online. |
| VHDX « introuvable » | LUN Offline ou non propriétaire | Dans le cluster, vérifier le propriétaire du CSV et l’état de la ressource disque. |
| Performances en dents de scie | IO redirigées CSV | Observer PerfMon « Cluster CSV File System » ; corriger latence/MPIO et réseau iSCSI. |
| Bascule iSCSI fréquente | Perte MTU / congestion | Vérifier MTU de bout en bout, files d’attente switch, éviter le partage avec trafic bruyant. |
| Échecs de migration | Incompatibilités Live Migration | Vérifier les versions CPU, les réseaux configurés et la bande passante disponible. |
Bonnes pratiques de structuration des volumes
- 1 CSV par groupe de VMs et par profil de performance (OLTP vs VDI, etc.).
- Aligner la taille des LUNs avec la croissance réelle ; éviter les CSV surdimensionnés difficiles à sauvegarder.
- Répartir les VMs par affinité de performance ; surveiller les hot‑spots (stats NAS et compteur CSV).
Questions fréquentes
Dois‑je reformater le LUN pour passer en CSV ?
Non. Vous ajoutez le disque en ressource de cluster puis vous l’ajoutez au CSV. Le volume est « virtualisé » sous ClusterStorage sans perte de données (assurez‑vous toutefois d’avoir une sauvegarde).
Pourquoi mes lettres de lecteurs changent‑elles ?
Après conversion en CSV, le volume n’a plus de lettre classique ; il est présenté via un point de montage standard C:\ClusterStorage\VolumeX. C’est intentionnel et nécessaire pour la cohérence sur tous les nœuds.
Peut‑on partager un LUN NTFS entre deux hôtes sans cluster ?
Non. Sans cluster / CSV, c’est une configuration non supportée et dangereuse (corruption potentielle).
Résumé exécutif
L’état Off‑Critical sur une VM Hyper‑V stockée sur iSCSI n’était pas un bug d’Hyper‑V mais la conséquence d’un LUN partagé sans orchestration de cluster. En créant le cluster, en convertissant le LUN en CSV et en stockant la VM sous C:\ClusterStorage, le chemin de stockage devient stable et la VM redémarre normalement, tout en gagnant la haute disponibilité (basculement et Live Migration).
Annexe : script de vérification rapide
$report = [ordered]@{}
$report['ClusterName'] = (Get-Cluster).Name
$report['Nodes'] = (Get-ClusterNode).Name -join ', '
$report['CSV'] = (Get-ClusterSharedVolume).Name -join ', '
$report['CSV_Owner'] = (Get-ClusterSharedVolume | Select-Object -First 1).OwnerNode.Name
$report['MSiSCSI'] = (Get-Service msiscsi).Status
$report['VMMS'] = (Get-Service vmms).Status
$report['DisksOffline'] = (Get-Disk | Where-Object OperationalStatus -ne 'Online').Number -join ', '
$report.GetEnumerator() | Sort-Object Name | ForEach-Object {
'{0,-15} : {1}' -f $*.Name, $*.Value
} Conclusion
En environnement Hyper‑V, le stockage partagé doit toujours être orchestré : soit via un CSV dans un cluster de basculement, soit via un partage SMB 3 hautement disponible. Présenter un LUN iSCSI en multi‑connect à plusieurs hôtes sans CSV mène tôt ou tard à des indisponibilités (état Off‑Critical) et au risque de corruption. En appliquant la démarche ci‑dessus (validation, cluster, CSV, MPIO, dépendances, tests), vous obtenez un socle robuste : les VMs redémarrent sans incident et basculent d’un hôte à l’autre de façon prévisible.
Récapitulatif du cas résolu
- Symptôme : VM en Off‑Critical après redémarrage, VHDX introuvable sur
D:. - Cause : LUN iSCSI partagé entre deux hôtes sans CSV/cluster.
- Action : Création du cluster, ajout du disque, conversion en CSV, déplacement des VMs sous
C:\ClusterStorage. - Résultat : VM stable après redémarrage, migrations et basculements OK.
Astuce finale : conservez un runbook détaillé (avec copies d’écran ou sorties PowerShell) et une fenêtre de test mensuelle pour vérifier le bon comportement des basculements, la validité des sauvegardes et le respect des bonnes pratiques réseau/stockage.