killtec

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.

screenshot 2025-07-14 122205

screenshot 2025-07-14 122215

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ß
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

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

em-pie
em-pie 14.07.2025 um 12:53:24 Uhr
Moin,

vorab, komme komplett aus der VMware Welt und habe noch nie ernsthaft mit HyperV (außer auf meinem Laptop) gearbeitet - daher um Nachsicht (face-wink)

  1. <Sarkasmus> es liegt bestimmt an der .local Domain </Sarkasmus>
  2. 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).
killtec
killtec 14.07.2025 um 13:13:28 Uhr
Zitat von @em-pie:
  1. <Sarkasmus> es liegt bestimmt an der .local Domain </Sarkasmus>
naja... ich denke nicht. Bei 1-2VMs war das mit nem alten Cluster auch, aber das ist ja passee...

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

Leider ist nichts offensichtliches drin. ISO's liegen auf dem CSV, sind aber alle nach Installation der jeweiligen VM wieder ungemounted worden. Netzwerktechnisch sind die Hosts alle identisch strukturiert (NIC Karten sind die gleichen, VMSwitch alles identisch), sonst hätte sich das Cluster nicht erstellen lassen.
user217
user217 14.07.2025 aktualisiert um 13:31:23 Uhr
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.
NordicMike
NordicMike 14.07.2025 um 13:45:04 Uhr
dann legt der Host auf dem zweiten Storage ein Dummyfile an
Ich kenne den HA Cluster nur mit einem gemeinsamen iSCSI Storage. Da würde es keinen ersten oder zweiten Storage geben.
user217
user217 14.07.2025 um 14:23:59 Uhr
Du kannst so viele Targets haben wie du willst und wenn beim umzug dazwischen einer auf die Fresse fliegt ..
killtec
killtec 14.07.2025 um 15:01:21 Uhr
Zu den Storages:
Es gibt nur eine Storage, die ist direkt per FC angebunden. Auf der Storage gibt es nur zwei Volumes. Eines mit SSD-Speicher und eines mit SAS Speicher. Wenige VM's benutzen beide Speicher. Fahre ich die VM herunter und migriere die klappt das. Nur nicht im Live-Betrieb.
user217
user217 14.07.2025 um 15:12:31 Uhr
das hört sich nach vmtools/hyperv client integrations software an oder?
MysticFoxDE
MysticFoxDE 14.07.2025 um 17:04:10 Uhr
Moin @killtec,

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
CH3COOH
CH3COOH 14.07.2025 um 17:12:35 Uhr
Hey,
ist der Memory der VMs fixed oder dynamisch? Und wie hoch ist der Memory eingestellt?
Gruß
killtec
killtec 15.07.2025 aktualisiert um 08:15:15 Uhr
Zitat von @MysticFoxDE:

Moin @killtec,

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

HI,
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}\

Die Umstellung von VMQ brachte keinen Erfolg.

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. Es sind 3 nodes. Alle identisch konfiguriert und installiert.
HA angelegt, VM's migriert.
Das Problem besteht bei selbigen alten VM's oder aber auch neuen VM's.
Etwas suspekt.

Bezüglich der Zeit, die bekommen sie vom DC der als Bare-Metal vorhanden ist.

Bezüglich NIC:
VM MGMT: 10G
VM Migration, Cluster: 10G
VM Switch: 25G

Zitat von @CH3COOH:

Hey,
ist der Memory der VMs fixed oder dynamisch? Und wie hoch ist der Memory eingestellt?
Gruß

Teils teils... Bei VM's wo DB's laufen (Oracle, MSSQL) fixed, bei anderen dynamisch.

Die HBA'S sind redundant angebunden und MPIO ist aktiv.

Gruß
MysticFoxDE
MysticFoxDE 15.07.2025 aktualisiert um 09:05:45 Uhr
Moin @killtec,

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?

clipboard-image

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
killtec
killtec 15.07.2025 um 14:42:07 Uhr
Hi,
Hier die Ausgabe für den VM Switch
PS C:\RESTORE> Get-VMSwitch | fl


Name                                             : Hyper-V-NET
Id                                               : 5fe0b18f-8844-49fe-9b1f-73a2710d26ab
Notes                                            :
Extensions                                       : {Microsoft Windows-Filterplattform, Microsoft-NDIS-Aufzeichnung}
BandwidthReservationMode                         : Absolute
PacketDirectEnabled                              : False
EmbeddedTeamingEnabled                           : False
AllowNetLbfoTeams                                : False
IovEnabled                                       : False
SwitchType                                       : External
AllowManagementOS                                : False
NetAdapterInterfaceDescription                   : Broadcom NetXtreme E-Series Dual-port 25Gb SFP28 Ethernet OCP 3.0 Adapter
NetAdapterInterfaceDescriptions                  : {Broadcom NetXtreme E-Series Dual-port 25Gb SFP28 Ethernet OCP 3.0 Adapter}
NetAdapterInterfaceGuid                          : {ca9d9dbc-d33e-4825-ae32-c46df1481358}
IovSupport                                       : False
IovSupportReasons                                : {SR-IOV wird von diesem Netzwerkadapter nicht unterstützt.}
AvailableIPSecSA                                 : 0
NumberIPSecSAAllocated                           : 0
AvailableVMQueues                                : 56
NumberVmqAllocated                               : 11
IovQueuePairCount                                : 71
IovQueuePairsInUse                               : 27
IovVirtualFunctionCount                          : 0
IovVirtualFunctionsInUse                         : 0
PacketDirectInUse                                : False
DefaultQueueVrssEnabledRequested                 : True
DefaultQueueVrssEnabled                          : True
DefaultQueueVmmqEnabledRequested                 : True
DefaultQueueVmmqEnabled                          : True
DefaultQueueVrssMaxQueuePairsRequested           : 16
DefaultQueueVrssMaxQueuePairs                    : 16
DefaultQueueVrssMinQueuePairsRequested           : 1
DefaultQueueVrssMinQueuePairs                    : 1
DefaultQueueVrssQueueSchedulingModeRequested     : StaticVrss
DefaultQueueVrssQueueSchedulingMode              : StaticVrss
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor          : False
SoftwareRscEnabled                               : True
RscOffloadEnabled                                : False
BandwidthPercentage                              : 10
DefaultFlowMinimumBandwidthAbsolute              : 2500000000
DefaultFlowMinimumBandwidthWeight                : 0
CimSession                                       : CimSession: .
ComputerName                                     : VMHOST1
IsDeleted                                        : False
DefaultQueueVmmqQueuePairs                       : 16
DefaultQueueVmmqQueuePairsRequested              : 16

Die Zeit passt (gerade noch mal kontrolliert).

Die CPU Hardwaretechnologie habe ich noch nicht nachgeschaut, werde ich noch nachholen.

Die komplette VM befindet sich auf dem Storage.
Es gibt zwei Volumes getrennt nach SSD only und SAS.
Manche VM's liegen nur auf einem Volume, manche auf beiden.
Beispiel:
(Gekürzte Verzeichnisse, nur zur Veranschaulichung)
VM 1 liegt auf c:\Volume1\VM1\VHD

VM2 liegt auf C:\Volume1\VM1\VHD und auf C:\Colume2\VM1\VHD

wobei die Configs immer auf Vol.1 sind. Genau so snapshots etc.

Es ist egal ob eine VM eine VHD auf beiden Volumens hat oder nicht.

fester RAM ist bei DB Servern fixiert, das andere sind eher unkritische VM's wie fileserver oder NPS.
killtec
killtec 15.07.2025 aktualisiert um 15:28:50 Uhr
clipboard-image

Das habe ich gerade mal bei einer VM gemacht (Unifi Controller auf einem Ubuntu). Half leider nicht.

Fehler in der Clusterressource "Virtueller Computer "unifi_vm"" des Typs "Virtual Machine" in der Clusterrolle "unifi_vm".  

Abhängig von den Fehlerrichtlinien für die Ressource und die Rolle wird vom Clusterdienst möglicherweise versucht, die Ressource auf diesem Knoten online zu schalten oder die Gruppe auf einen anderen Knoten des Clusters zu verschieben und die Ressource dann neu zu starten. Prüfen Sie den Ressourcen- und Gruppenzustand mit dem Failovercluster-Manager oder mit dem Windows PowerShell-Cmdlet "Get-ClusterResource".  

Der Clusterdienst konnte die Clusterrolle "unifi_vm" nicht vollständig online oder offline schalten. Möglicherweise befindet sich mindestens eine Ressource in einem fehlerhaften Zustand. Dies kann sich auf die Verfügbarkeit der Clusterrolle auswirken.  

Die Clusterrolle ist jedoch online..
PS C:\Windows\system32> Get-ClusterResource

Name                                                   State  OwnerGroup      ResourceType
----                                                   -----  ----------      ------------
CAUROH-Cuew                                            Online CAUROH-Cuew     Distributed Network Name
CAUROH-Cuewp3ae                                        Online CAUROH-Cuewp3ae Distributed Network Name
CAUROH-CuewResource                                    Online CAUROH-Cuew     ClusterAwareUpdatingResource
Clusterdatenträger 3                                   Online Clustergruppe   Physical Disk
Cluster-IP-Adresse                                     Online Clustergruppe   IP Address
Clustername                                            Online Clustergruppe   Network Name
Konfiguration des virtuellen Computers "Apptec_MDM"    Online Apptec_MDM      Virtual Machine Configuration  
Konfiguration des virtuellen Computers "COMtrexx"      Online COMtrexx        Virtual Machine Configuration  
[...]
Konfiguration des virtuellen Computers "unifi_vm"      Online unifi_vm        Virtual Machine Configuration  
CAUCLUS24                                          Online CAUROH-Cuewy16e Distributed Network Name
Speicher-QoS-Ressource                                 Online Clustergruppe   Storage QoS Policy Manager
Virtual Machine Cluster WMI                            Online Clustergruppe   Virtual Machine Cluster WMI
Virtueller Computer "Apptec_MDM"                       Online Apptec_MDM      Virtual Machine  
Virtueller Computer "COMtrexx"                         Online COMtrexx        Virtual Machine  
[...]
Virtueller Computer "unifi_vm"                         Online unifi_vm        Virtual Machine  

Hier noch die Config:
network
cluster
switch
screenshot 2025-07-15 152541
MysticFoxDE
MysticFoxDE 16.07.2025 aktualisiert um 08:22:33 Uhr
Moin @killtec,

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
MysticFoxDE
MysticFoxDE 16.07.2025 um 08:30:39 Uhr
Moin @killtec,

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
killtec
killtec 16.07.2025 aktualisiert um 14:32:56 Uhr
Hi Alex,
die ubuntu VM mag das nicht.
screenshot 2025-07-16 143000

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.

Das mit dem VMQ klingt interessant. Wüsste nicht mehr dass ich das konfiguriert habe.
user217
user217 16.07.2025 um 15:35:53 Uhr
Zitat von @user217:

das hört sich nach vmtools/hyperv client integrations software an oder?

Hyper-V Integration Services (auch: Integration Components)
killtec
killtec 18.07.2025 um 08:52:35 Uhr
Zitat von @user217:

Zitat von @user217:

das hört sich nach vmtools/hyperv client integrations software an oder?

Hyper-V Integration Services (auch: Integration Components)

Meintest du das hier?
So sind alle VM's eingestellt
screenshot 2025-07-18 085014

@MysticFoxDE
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.

P.S.: Kann dann erst übernächste Woche weiter dran arbeiten, also bitte nicht wundern wenn dann Antworten etwas dauern.
user217
user217 18.07.2025 um 09:07:07 Uhr
Meintest du das hier?
So sind alle VM's eingestellt

Und die laufen alle sauber? sfc /scan, dism /health etc.?
Mal per Konsole drauf und alle löschen/neu installieren.

Was macht eine frisch installierte testmaschine mit win11 z.B. migriert die sauber?
killtec
killtec 18.07.2025 um 11:20:35 Uhr
Zitat von @user217:
Und die laufen alle sauber? sfc /scan, dism /health etc.?
Mal per Konsole drauf und alle löschen/neu installieren.

Was macht eine frisch installierte testmaschine mit win11 z.B. migriert die sauber?

Die VM's laufen sauber.
Wieso sollte ich in einer produktivumgeben alle VM's löschen und neu installieren? Das ist nicht zielführend.
Test VM kann ich gerne noch mal testen.

Gruß
MysticFoxDE
MysticFoxDE 18.07.2025 um 11:47:59 Uhr
Moin @killtec,

die ubuntu VM mag das nicht.
screenshot 2025-07-16 143000

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
MysticFoxDE
MysticFoxDE 18.07.2025 aktualisiert um 11:51:51 Uhr
Moin @killtec,

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.

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