Live Migration Error, bei Hosts mit gleicher CPU

Bereits im Sommer habe ich euch von einem Fehler bei der Live Migration berichtet, der sich auf die processorspezifischen Features der CPU bezieht hier geht es zu diesem Blogbeitrag. Heute geht es zwar um die gleiche Fehlermeldung, doch die Ursache ist eine andere. Folgender Fehler wird angezeigt:

Live migration of <VMName> failed.

Virtual machine migration operation for <VMName> failed at migration destination <ServerName>. (Virtual machine ID <GuidIDderVM>.

The virtual machine <VMName> is unsing processor-specific features not supported on physical computer <ServerName>. To allow for migration of this virtual machine to physical computers with different processors. modify the virtual machine settings to limit the processor features used by the virtual machine. (Virtual machine ID <GuidIDderVM>

hier noch die deutsche Fehlermeldung:

Fehler bei der Livemigration von <VMName>.

Fehler beim Migrationsvorgang für den virtuellen Computer <VMName> am Migrationsziel <ServerName>. (ID des virtuellen Computers: <GuidIDderVM>)

Für den virtuellen Computer <VMName> werden prozessorspezifische Features verwendet, die auf dem physikalischen Computer <ServerName> nicht unterstützt werden. Ändern Sie die Einstellungen des virtuellen Computers, um die vom virtuellen Computer verwendeten Prozessorfeatures zu beschränken, wenn Sie die Migration des virtuellen Computers zu physikalischen Computern mit anderen Prozessoren zulassen möchten. (ID des virtuellen Computers: <GuidIDderVM>)

prcessor-specific features are not supported

Was ist die Ursache dieser Fehlermeldung?

Warum schlägt die Live Migration fehl, obwohl alle Server im Cluster die gleiche CPU haben und auch alle Server den gleichen Patchstand - ihr erinnert euch, dies war die Ursache bei meinem ersten Blogbeitrag zu diesem Fehler.

Ein Blogbeitrag von Eric Siron brachte mich ganz schnell auf die Fehlerursache. An dieser Stelle ein herzliches Dankeschön an Eric Siron für diesen tollen und ausführlichen Blogbeitrag. Ich möchte euch an dieser Stelle nur die Lösungsmöglichkeit beschreiben. Wer nähere Infos nachlesen möchte über das weshalb und warum, findet die Infos in dem oben verlinkten Blogbeitrag von Eric Sirion.

Mit dem Befehl

gwmi win32_bios

ausgeführt in einem administrativen CMD Fenster, konnte ich feststellen, dass zwei der Kundenserver aus dem vier Knotencluster eine ältere Bios Version aufwiesen, als die Beiden anderen.

Nachdem wir die Bios Versionen auf dem zwei betroffenen Servern upgedaten hatten, konnten wir die VMs ohne Probleme zwischen den vier Knoten des Failover Clusters hin und her vrschieben.

Ich hoffe, ich konnte euch auch mit diesem kurzen Blogbeitrag helfen.

Bis Bald und viel Erfolg

Petra

←Previous post Next post→

Petra Lipp

Petra Lipp ist ausgebildete Datenverarbeitungskauffrau mit mehr als 20 jähriger Berufserfahrung. Seit Februar 2015 verstärkt sie das Team der Rachfahl IT-Solutions GmbH & Co KG. Petra Lipp ist VEEAM Certified Engineer (VMCE), MCSE Private Cloud.

Henning Uhle sagt:

11. Oktober 2020 um 14:51 Uhr

Hallo Petra,

danke für den Artikel. Aber es ist auch nicht ganz ungewöhnlich. Ich arbeite seit 14 Jahren im IT-Support und habe dort – auch – immer wieder mit Failover-Clustern zu tun gehabt. Die verrücktesten Probleme wurden verursacht, weil solche Dinge wie Treiber- und Firmware-Stände und BIOS etc. nicht gleich waren. Ein Hyper-V-Cluster ist ja auch erstmal ein Failover-Cluster. Also wird das da vergleichbar sein.

Wenn irgendwas komisch ist in einem (Hyper-V)-Failover-Cluster, fordere ich mir immer ein ganzes Bündel Logs an, bei denen neben Eventlogs und Clusterlogs und weiß der Deibel, was alles, auch die MSINFO dabei ist. Hier braucht man eigentlich „nur“ zu vergleichen.

Ich finde es dennoch gut, dass ihr darüber geschrieben habt. Deshalb abschließend nochmal: Danke für den Artikel.