Live Migration fails on Hyper-V 2016 Cluster

Bonjour,

je confirme que les deux hôtes disposent du même BIOS :

• SMBIOSBIOSVersion : P89
• Manufacturer : HP
• Cordialement,

Bonjour

J’ai exécuté la commande Compare-VM pour la machine virtuelle SRV-DCS lors de la migration vers l’hôte CEPEX-HV2, et voici le résultat :

• Incompatibilités détectées : 21026, 24004

Merci d’avance pour votre aide.

Cordialement,

Bonjour,

Désolé pour le retard de retour, j’étais en congé et je n’ai pas pu effectuer les tests plus tôt.

J’ai vérifié aujourd’hui sur la machine concernée, cependant je n’ai pas trouvé les clés de registre mentionnées (FeatureSettingsOverride, FeatureSettingsOverrideMask ni les paramètres liés à DeviceGuard).

Pouvez-vous me confirmer si ces clés doivent être créées manuellement si elles sont absentes, ou si leur absence indique que ces mécanismes (atténuations CPU / VBS) ne sont pas activés sur le système ?

Merci d’avance pour votre aide.

Cordialement,

Bonjour John Lamma,

Comment se passe ton problème ? Est-ce que cela a été résolu ? Si c'est le cas, merci d 'accepter la réponse car cela aide aussi d'autres personnes partageant le même problème. Merci :)

Vice-président

Bonjour John Lamma,

Le code d'erreur 24004 indique que l'hyperviseur détecte un décalage de fonctionnalité spécifique au processeur lors des pré-vérifications de migration en direct. Parce qu'une toute nouvelle machine virtuelle fonctionne parfaitement, le problème est certainement intégré à l'état du système d'exploitation invité de votre ancienne disquette VHDX. Le coupable le plus courant de ce scénario exact sur Windows Server 2016 concerne les mesures CPU au niveau logiciel pour des vulnérabilités comme Spectre et Meltdown. Dans le système d'exploitation invité, naviguez vers le chemin du registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management et cherchez les valeurs FeatureSettingsOverride et FeatureSettingsOverrideMask. Si l'ancienne installation présente des états d'atténuation différents de ceux attendus par l'hôte physique, l'hyperviseur bloquera la migration.

Un autre obstacle potentiel dans l'ancien VHDX est la Virtualization-Based Security ou Credential Guard. Lorsqu'il est activé, le chargeur d'amorçage du système d'exploitation invité verrouille des registres processeurs spécifiques pour protéger le noyau sécurisé. Si l'hyperviseur tente de sérialiser ces registres verrouillés lors d'une migration en direct, il perçoit un décalage matériel et génère des erreurs de migration génériques. Vous pouvez vérifier cela en vérifiant le chemin du registre invité HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard et en voyant si la clé EnableVirtualizationBasedSecurity est active.

Puisque vos hôtes physiques possèdent des architectures Intel Xeon identiques, maintenir le paramètre de compatibilité CPU activé peut parfois masquer de manière inattendue les jeux d'instructions et introduire des conflits artificiels dans la couche d'abstraction. Essayez de désactiver complètement ce paramètre pour que l'hyperviseur transmette directement l'état brut du processeur à l'invité. Enfin, la meilleure façon d'arrêter de deviner et d'identifier le blocage exact est d'ouvrir PowerShell sur votre hôte source et d'exécuter le cmdlet Compare-VM ciblant votre machine virtuelle et le nœud hôte de destination. Inspecter la propriété d'incompatibilités à partir de la sortie de cette commande révélera l'ID matériel exact ou l'état du processeur que l'hyperviseur rejette.

J'espère que cette réponse vous a apporté des informations utiles. Si c'est le cas, veuillez cliquer sur « accepter la réponse ». Si vous avez des questions, n'hésitez pas à laisser un commentaire.

Vice-président