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>)
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