Hyper-VA HA Cluster Problem Live-Migration
Hallo,
ich habe ein Hyper-V HA Cluster bestehend aus 3x Server 2022 Std die auf ein SAN zugreifen.
Das Cluster an sich funktioniert, nur besteht das Problem darin, dass einige VM's nicht Live migriert werden können.
Die Ereignisanzeige brachte keine Erkenntnisse über die eigentliche Ursache. Hier sind die Fehler IDs 1155: Verschiebung konnte nicht abgeschlossen werden und 1137 konnte nicht Abgeschlossen werden Fehelercode 0x5B4.
Das hat leider zur Folge, dass die Server sich nicht korrekt über die CAU Rolle aktualisieren, da die Rollen nicht ausgeglichen werden können.
Auch ist es so nicht ohne weiteres Möglich den Server in einen Wartungszustand zu packen um ihn z.B. neu zu starten.
Alle OSse sind auf aktuellen Stand, die Hardware ist auch identisch, so dass Software und Hardware erst einmal passend sind.


Die Ereignisanzeige direkt auf dem Server brachte mich bisher auch nicht weiter.
Es ist hierbei auch egal ob es eine Windows oder Linux-VM ist. Schnellmigration klappt.
Über Tipps bin sich sehr dankbar.
Gruß
ich habe ein Hyper-V HA Cluster bestehend aus 3x Server 2022 Std die auf ein SAN zugreifen.
Das Cluster an sich funktioniert, nur besteht das Problem darin, dass einige VM's nicht Live migriert werden können.
Die Ereignisanzeige brachte keine Erkenntnisse über die eigentliche Ursache. Hier sind die Fehler IDs 1155: Verschiebung konnte nicht abgeschlossen werden und 1137 konnte nicht Abgeschlossen werden Fehelercode 0x5B4.
Das hat leider zur Folge, dass die Server sich nicht korrekt über die CAU Rolle aktualisieren, da die Rollen nicht ausgeglichen werden können.
Auch ist es so nicht ohne weiteres Möglich den Server in einen Wartungszustand zu packen um ihn z.B. neu zu starten.
Alle OSse sind auf aktuellen Stand, die Hardware ist auch identisch, so dass Software und Hardware erst einmal passend sind.


Die Ereignisanzeige direkt auf dem Server brachte mich bisher auch nicht weiter.
Es ist hierbei auch egal ob es eine Windows oder Linux-VM ist. Schnellmigration klappt.
Über Tipps bin sich sehr dankbar.
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673856
Url: https://administrator.de/forum/hyper-v-cluster-live-migration-problem-673856.html
Ausgedruckt am: 03.08.2025 um 20:08 Uhr
22 Kommentare
Neuester Kommentar
Moin,
vorab, komme komplett aus der VMware Welt und habe noch nie ernsthaft mit HyperV (außer auf meinem Laptop) gearbeitet - daher um Nachsicht (
)
vorab, komme komplett aus der VMware Welt und habe noch nie ernsthaft mit HyperV (außer auf meinem Laptop) gearbeitet - daher um Nachsicht (
- <Sarkasmus> es liegt bestimmt an der .local Domain </Sarkasmus>
- du schreibst "... dass einige VM's nicht Live migriert werden können.". Daraus impliziere ich (und schreibst du weiter unten selbst), dass andere VMs sich migrieren lassen. Hängt an diesen VMs irgendwas, was mit dem Host verbunden ist? Hardware-Geräte (wie USB-Dongles) oder ISOs (die auf dem Host liegen), sind die NICs am vSwitch überall identisch (ich weiß von VMware, dass wenn das VLAN 101 am Host A Clients und am Host B Client heißt, es Probleme gibt).
Das passiert wenn das Storage während der Migration/LiveBetrieb zu lange ausfällt bzw. offline ist, dann legt der Host auf dem zweiten Storage ein Dummyfile an (hat ja schon die migration begonnen) wordurch die nachträgliche Migration gesperrt wird.
Ich würde:
1. Notieren welche Systeme betroffen sind
2. auf alle Storages die vm zugehörigen Ordner suchen und je nach zustand auf dem alten storage löschen (reste..)
3. Falls das auch nix bringt würde ich ein backup machen, vm löschen, alle Ordner auf dem storgage löschen und recovern
Oft sind solche Systeme nach einer fehlerhaften migration teilw. inkonsistent. D.h. am besten gleich recovern wenns geht, wenns nicht geht dann anschließend unbedingt sfc /scannow drüber laufen lassen.
Ich würde:
1. Notieren welche Systeme betroffen sind
2. auf alle Storages die vm zugehörigen Ordner suchen und je nach zustand auf dem alten storage löschen (reste..)
3. Falls das auch nix bringt würde ich ein backup machen, vm löschen, alle Ordner auf dem storgage löschen und recovern
Oft sind solche Systeme nach einer fehlerhaften migration teilw. inkonsistent. D.h. am besten gleich recovern wenns geht, wenns nicht geht dann anschließend unbedingt sfc /scannow drüber laufen lassen.
Moin @killtec,
das Problem kann unterschiedliche Gründe haben und das ...
... ist so leider nicht richtig.
Prüfe bitte mal zuerst, ob die Zeit auf den Nodes überall dieselbe ist.
Kannst du auf einem der Nodes bitte ...
... ausführen und die Ausgabe hier posten, danke.
Sind auf den VM's die sich nicht Live migrieren lassen, irgendwelche Snapshots aktiv?
Schalte auf den vNIC's der VM's auch mal das VMQ aus, was per default immer aktiv ist und versuche die Live-Migration danach mal erneut.
Sind die Probleme von heute auf morgen gekommen oder war das quasi schon immer so?
Gruss Alex
das Problem kann unterschiedliche Gründe haben und das ...
"Netzwerktechnisch sind die Hosts alle identisch strukturiert (NIC Karten sind die gleichen, VMSwitch alles identisch), sonst hätte sich das Cluster nicht erstellen lassen."
... ist so leider nicht richtig.
Prüfe bitte mal zuerst, ob die Zeit auf den Nodes überall dieselbe ist.
Kannst du auf einem der Nodes bitte ...
Get-ClusterSharedVolumeState
... ausführen und die Ausgabe hier posten, danke.
Sind auf den VM's die sich nicht Live migrieren lassen, irgendwelche Snapshots aktiv?
Schalte auf den vNIC's der VM's auch mal das VMQ aus, was per default immer aktiv ist und versuche die Live-Migration danach mal erneut.
Sind die Probleme von heute auf morgen gekommen oder war das quasi schon immer so?
Gruss Alex
Moin @killtec,
das sieht schon mal gut aus, sprich, die CSV's sind zum Glück nicht ReFS, sondern NTFS formatiert. 👍
OK, damit ist das Thema Netzwerk, jedoch nicht wirklich vom Tisch.
Kannst du als nächstes auf einem der Nodes mal das folgende ...
... ausführen und die entsprechende Ausgabe auch mal hier posten, danke.
Die VM's sind also ursprünglich mal auf einer anderen Hardware gelaufen, interessant.
Hast du nach der Migration der VM, in deren Einstellungen auch schon die CPU Hardwaretopologie an die neuen Nodes angeglichen?

Geht aber nur im ausgeschalteten Zustand.
Hast du dennoch mal kontrolliert, ob die Zeit auf den HV Nodes wirklich gleich ist?
Oh, noch eine Sache ... befinden sich wirklich alle Teile der VM auf einem CSV, sprich, sowohl die Konfigurationsdatei, als auch die vDisks und auch die Snapshots?
Dynamischer RAM ist vor allem performancetechnisch eher mit Vorsicht zu geniessen. 😬
Gruss Alex
hier der Output:
PS C:\Windows\system32> Get-ClusterSharedVolumeState
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 1
Node : VMHOST2
StateInfo : Direct
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{26d8740d-3553-480e-8c82-3350c25c895f}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 1
Node : VMHOST3
StateInfo : Direct
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{26d8740d-3553-480e-8c82-3350c25c895f}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 1
Node : VMHOST1
StateInfo : Direct
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{26d8740d-3553-480e-8c82-3350c25c895f}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 2
Node : VMHOST2
StateInfo : Direct
VolumeFriendlyName : Volume2
VolumeName : \\?\Volume{36d8bd36-dd65-423d-8f9c-f20982ec2534}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 2
Node : VMHOST3
StateInfo : Direct
VolumeFriendlyName : Volume2
VolumeName : \\?\Volume{36d8bd36-dd65-423d-8f9c-f20982ec2534}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 2
Node : VMHOST1
StateInfo : Direct
VolumeFriendlyName : Volume2
VolumeName : \\?\Volume{36d8bd36-dd65-423d-8f9c-f20982ec2534}\
das sieht schon mal gut aus, sprich, die CSV's sind zum Glück nicht ReFS, sondern NTFS formatiert. 👍
Die Umstellung von VMQ brachte keinen Erfolg.
OK, damit ist das Thema Netzwerk, jedoch nicht wirklich vom Tisch.
Kannst du als nächstes auf einem der Nodes mal das folgende ...
Get-VMSwitch | FL
... ausführen und die entsprechende Ausgabe auch mal hier posten, danke.
Das Problem war bei 1-2 VM'S in einem alten Hyper-V 2016 Cluster vorhanden. Dann wurde Harware und Hyper-V Cluster komplett erneuert mit Server 2022 und Hyper-V, sonst läuft da nichts weiter drauf.
Die VM's sind also ursprünglich mal auf einer anderen Hardware gelaufen, interessant.
Hast du nach der Migration der VM, in deren Einstellungen auch schon die CPU Hardwaretopologie an die neuen Nodes angeglichen?

Geht aber nur im ausgeschalteten Zustand.
Bezüglich der Zeit, die bekommen sie vom DC der als Bare-Metal vorhanden ist.
Hast du dennoch mal kontrolliert, ob die Zeit auf den HV Nodes wirklich gleich ist?
Oh, noch eine Sache ... befinden sich wirklich alle Teile der VM auf einem CSV, sprich, sowohl die Konfigurationsdatei, als auch die vDisks und auch die Snapshots?
Teils teils... Bei VM's wo DB's laufen (Oracle, MSSQL) fixed, bei anderen dynamisch.
Dynamischer RAM ist vor allem performancetechnisch eher mit Vorsicht zu geniessen. 😬
Gruss Alex
Moin @killtec,
ähm, ja, ich versuche es so schmerzlos wie möglich.
Dein System ist für VMQ überhaupt nicht korrekt konfiguriert, daher solltest du es am besten bei allen VM's auch ausschalten. Zumindest so lange, bis er richtig konfiguriert wurde.
Kurze Erklärung, der Wert „AvailableVMQueues“ gibt an, wie viele vNIC mit VMQ stand der aktuellen Konfiguration überhaupt möglich sind. Sprich, laut deiner Konfiguration kannst du über diesen vSwitch, theoretisch bis zu 56 vNIC's mit VMQ betreiben, was übrigens für eine 25G NIC eher ein Witz ist.
Wie auch immer, jede vNIC bei der VMQ oder SRIOV aktiviert ist, frisst aber auch IovQueuePairs und zwar bis zu 16 pro vNIC, weil DefaultQueueVmmqQueuePairsRequested = 16.
Und ja, dieser Parameter steuert primär eigentlich die IovQueuePairs der DefaultQueue des entsprechenden vSwitches … sekundär steuert dieser aber auch die max. IovQueuePairs der VMQ-vNIC‘s.
Der entsprechende Port deiner pNIC, stellt bei der jetzigen Konfiguration in Summe jedoch nur 71 IovQueuePairs zur Verfügung, was im ungünstigsten Fall, sprich, bei 16 QP’s pro VMQ-vNIC, für gerade mal 71 / 16 = 4,4375 VMQ-vNIC’s reichen würde. 🙃
Details gerne später, bin gerade etwas im Stress.
Gruss Alex
PS C:\RESTORE> Get-VMSwitch | fl
NetAdapterInterfaceDescription : Broadcom NetXtreme E-Series Dual-port 25Gb SFP28 Ethernet OCP 3.0 NetAdapterInterfaceDescriptions : {Broadcom NetXtreme E-Series Dual-port 25Gb SFP28 Ethernet OCP 3.0 Adapter}
AvailableVMQueues : 56
NumberVmqAllocated : 11
IovQueuePairCount : 71
IovQueuePairsInUse : 27
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 16
DefaultQueueVmmqQueuePairs : 16
DefaultQueueVmmqQueuePairsRequested : 16
ähm, ja, ich versuche es so schmerzlos wie möglich.
Dein System ist für VMQ überhaupt nicht korrekt konfiguriert, daher solltest du es am besten bei allen VM's auch ausschalten. Zumindest so lange, bis er richtig konfiguriert wurde.
Kurze Erklärung, der Wert „AvailableVMQueues“ gibt an, wie viele vNIC mit VMQ stand der aktuellen Konfiguration überhaupt möglich sind. Sprich, laut deiner Konfiguration kannst du über diesen vSwitch, theoretisch bis zu 56 vNIC's mit VMQ betreiben, was übrigens für eine 25G NIC eher ein Witz ist.
Wie auch immer, jede vNIC bei der VMQ oder SRIOV aktiviert ist, frisst aber auch IovQueuePairs und zwar bis zu 16 pro vNIC, weil DefaultQueueVmmqQueuePairsRequested = 16.
Und ja, dieser Parameter steuert primär eigentlich die IovQueuePairs der DefaultQueue des entsprechenden vSwitches … sekundär steuert dieser aber auch die max. IovQueuePairs der VMQ-vNIC‘s.
Der entsprechende Port deiner pNIC, stellt bei der jetzigen Konfiguration in Summe jedoch nur 71 IovQueuePairs zur Verfügung, was im ungünstigsten Fall, sprich, bei 16 QP’s pro VMQ-vNIC, für gerade mal 71 / 16 = 4,4375 VMQ-vNIC’s reichen würde. 🙃
Details gerne später, bin gerade etwas im Stress.
Gruss Alex
Moin @killtec,
lösch mal bitte testweise die Cluster-Rolle für diese VM und versuche anschliessend mal bitte dieselbe VM über die Hyper-V Console zwischen den Hosts zu migrieren. Vielleicht bekommst du über diesen Weg auch eine etwas mehr aussagende Fehlermeldung. 😉
Gruss Alex
Das habe ich gerade mal bei einer VM gemacht (Unifi Controller auf einem Ubuntu). Half leider nicht.
lösch mal bitte testweise die Cluster-Rolle für diese VM und versuche anschliessend mal bitte dieselbe VM über die Hyper-V Console zwischen den Hosts zu migrieren. Vielleicht bekommst du über diesen Weg auch eine etwas mehr aussagende Fehlermeldung. 😉
Gruss Alex
Hyper-V Integration Services (auch: Integration Components)
Moin @killtec,
🤔 ... versuch mal zuerst die entsprechende VM per Storage-Live-Migration entweder auf ein anderes CSV oder in ein anderes Verzeichnis zu verschieben.
Und wenn das funktioniert hat, anschliessend eine normale Live-Migration zwischen den Nodes versuchen.
Mach dir keinen Kopf, das macht so gut wie keiner, weil die meisten von VMQ oder SR-IOV, auch noch nicht viel gehört haben. Und obwohl es diese Technologie eigentlich schon seit etwa 2008 gibt, ist diese auch im Jahr 2025 noch sehr stiefmütterlich dokumentiert. 😔😭
Gruss Alex
die ubuntu VM mag das nicht.

Ich habe dann selbiges mal mit einer Windows VM (Windows CA) gemacht, das lief problemlos durch. Danach auch im Failover Manager.
Oftmals läuft es bis ca. 57% durch und bleibt dann stehen.

Ich habe dann selbiges mal mit einer Windows VM (Windows CA) gemacht, das lief problemlos durch. Danach auch im Failover Manager.
Oftmals läuft es bis ca. 57% durch und bleibt dann stehen.
🤔 ... versuch mal zuerst die entsprechende VM per Storage-Live-Migration entweder auf ein anderes CSV oder in ein anderes Verzeichnis zu verschieben.
Und wenn das funktioniert hat, anschliessend eine normale Live-Migration zwischen den Nodes versuchen.
Das mit dem VMQ klingt interessant.
Das ist nicht nur interessant, sondern ist, wenn du eine >= 10G NIC in Verbindung mit einem Hypervisor, sprich auf VM-Ebene ausnutzen möchtest, quasi die Mindestanforderung.Wüsste nicht mehr dass ich das konfiguriert habe.
Mach dir keinen Kopf, das macht so gut wie keiner, weil die meisten von VMQ oder SR-IOV, auch noch nicht viel gehört haben. Und obwohl es diese Technologie eigentlich schon seit etwa 2008 gibt, ist diese auch im Jahr 2025 noch sehr stiefmütterlich dokumentiert. 😔😭
Gruss Alex
Moin @killtec,
folgendes Angebot.
Mach du jetzt erstmal Urlaub und erhole dich ein bisschen und wenn du zurück bist, dann können wir gerne eine kleine Remotesession machen, bei der ich dir erkläre worauf du alles achten musst und dann verstehst du auch, dass dein Wunsch nach diesem Link, so leider nicht einfach umzusetzen ist.
Gruss Alex
zum Verständnis des VMQ, das muss auf der NIC aktiv sein, die für die VM's ist und nicht für die Verwaltung, korrekt?
Hast du einen Link wo ich mich mal in das VMQ einlesen kann.
Hast du einen Link wo ich mich mal in das VMQ einlesen kann.
folgendes Angebot.
Mach du jetzt erstmal Urlaub und erhole dich ein bisschen und wenn du zurück bist, dann können wir gerne eine kleine Remotesession machen, bei der ich dir erkläre worauf du alles achten musst und dann verstehst du auch, dass dein Wunsch nach diesem Link, so leider nicht einfach umzusetzen ist.
Gruss Alex