12
Frage zu Hyper-V Live Migration
Hallo,
mir ist ein komisches Verhalten beim Versuch einer Live Migration aufgefallen.
Vorab:
Es handelt sich um zwei verschiedene Server mit unterschiedlich alten Intel CPUs.
Der CPU des alten Servers ist ein Intel Xeon Silver 4110 Prozessor.
Der CPU des neuen Servers ist ein Intel Xeon Silver 4410Y Prozessor.
Wenn ich vom neuen Server zum alten eine Live Migration anstoßen will zeigt es mir einen Fehler an, dass der andere Server(alte Server) Prozessorspezifische Eingeschaften nicht unterstützen würde. Schalte ich die VM aus und migriere sie ohne Kompatibilitätsmodus geht es trotzdem und die VM startet ohne Probleme auf dem anderen Host.
Will ich die VM zurück migrieren kann ich die Live Migration ohne Probleme ausführen ohne Fehler.
Leider ist die Fehlermeldung nicht gerade hilfreich, was überhaupt das Problem ist. Selbst wenn ich den Kompatibilitätsmodus aktiviere in der VM wirft er mir diesen Fehler und bricht die Migration ab. Ist die VM aus geht es.
Jetzt gab es für die alte CPU damals jede Menge Mitigationen per BIOS Updates. Kann das daran liegen?
Was könnte ich evtl. in den Einstellungen probieren um eine Live Migration vom neuen Server zum alten Server erfolgreich durchzuführen?
Wäre für Ideen dankbar
mir ist ein komisches Verhalten beim Versuch einer Live Migration aufgefallen.
Vorab:
Es handelt sich um zwei verschiedene Server mit unterschiedlich alten Intel CPUs.
Der CPU des alten Servers ist ein Intel Xeon Silver 4110 Prozessor.
Der CPU des neuen Servers ist ein Intel Xeon Silver 4410Y Prozessor.
Wenn ich vom neuen Server zum alten eine Live Migration anstoßen will zeigt es mir einen Fehler an, dass der andere Server(alte Server) Prozessorspezifische Eingeschaften nicht unterstützen würde. Schalte ich die VM aus und migriere sie ohne Kompatibilitätsmodus geht es trotzdem und die VM startet ohne Probleme auf dem anderen Host.
Will ich die VM zurück migrieren kann ich die Live Migration ohne Probleme ausführen ohne Fehler.
Leider ist die Fehlermeldung nicht gerade hilfreich, was überhaupt das Problem ist. Selbst wenn ich den Kompatibilitätsmodus aktiviere in der VM wirft er mir diesen Fehler und bricht die Migration ab. Ist die VM aus geht es.
Jetzt gab es für die alte CPU damals jede Menge Mitigationen per BIOS Updates. Kann das daran liegen?
Was könnte ich evtl. in den Einstellungen probieren um eine Live Migration vom neuen Server zum alten Server erfolgreich durchzuführen?
Wäre für Ideen dankbar
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 12111801561
Url: https://administrator.de/forum/frage-zu-hyper-v-live-migration-12111801561.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Gruss,
Peter
Intel Xeon Silver 4410Y
Der CPU des alten Servers ist ein Intel Xeon Silver 4110 Prozessor.
Kein Intel Xeon Silver 4110 T?Der CPU des alten Servers ist ein Intel Xeon Silver 4110 Prozessor.
Der CPU des neuen Servers ist ein Intel Xeon Silver 4410Y Prozessor.
Beide von 2023Wäre für Ideen dankbar
Was steht in der Fehlermeldung denn drin, nur Kakao vergessen oder keine Milch?Gruss,
Peter
Moin @preysa,
meine Kristallkugel sagt mir, dass die beiden Hyper-V's wahrscheinlich stand-alone, sprich, nicht geclustert sind.
Wenn ja, dann ist das was du beschreibst ganz normal, denn das mit dem "Kompatibilitätsmodus" funktioniert nur bei einem Cluster.
Gruss Alex
Was könnte ich evtl. in den Einstellungen probieren um eine Live Migration vom neuen Server zum alten Server erfolgreich durchzuführen?
meine Kristallkugel sagt mir, dass die beiden Hyper-V's wahrscheinlich stand-alone, sprich, nicht geclustert sind.
Wenn ja, dann ist das was du beschreibst ganz normal, denn das mit dem "Kompatibilitätsmodus" funktioniert nur bei einem Cluster.
Gruss Alex
Es geht um diese CPU
https://ark.intel.com/content/www/de/de/ark/products/123547/intel-xeon-s ...
Das ist der Fehler:
https://ark.intel.com/content/www/de/de/ark/products/123547/intel-xeon-s ...
Das ist der Fehler:
Ich hab die beiden Hosts wie zum Beispiel hier im Video im Hyper-V Manager hinzugefügt
https://www.youtube.com/watch?v=cVEdAyce9NI
Das ganze läuft über Kerberos, die Delegierung ist eingestellt und funktioniert. Ich kann von HV-01 zum Beispiel HV-02 kofigurieren und anders herum.
https://www.youtube.com/watch?v=cVEdAyce9NI
Das ganze läuft über Kerberos, die Delegierung ist eingestellt und funktioniert. Ich kann von HV-01 zum Beispiel HV-02 kofigurieren und anders herum.
Moin,
Das Verhalten ist vollkommen normal. Die CPUs stammen aus unterschiedlichen Generationen. Der neue Prozessor unterstützt Features / Flags, die es auf dem alten Prozessor schlicht noch nicht gibt. Daher kannst du von neu -> alt nicht live migrieren, da der Zustand des Prozessors auf dem alten Host nicht nachgebildet werden kann.
Anders herum geht es, weil der neue Prozessor (logischerweise) auch das Featureset des älteren unterstützt.
Bei ausgeschalteten VMs geht es deswegen, weil das Gast OS den Prozessor ja erst beim Booten initialisiert und die Features erkennt.
In Clustern würde die Migration auch nur laufen, wenn der neuere Host im Kompatibilitätsmodus läuft. Dadurch würde sein Prozessor künstlich auf das Featureset des alten beschränkt, wodurch eine Live Migration wieder möglich wäre.
Der 4110 ist aus 2017 und der 4410Y aus 2023...
Gruß,
Avoton
Das Verhalten ist vollkommen normal. Die CPUs stammen aus unterschiedlichen Generationen. Der neue Prozessor unterstützt Features / Flags, die es auf dem alten Prozessor schlicht noch nicht gibt. Daher kannst du von neu -> alt nicht live migrieren, da der Zustand des Prozessors auf dem alten Host nicht nachgebildet werden kann.
Anders herum geht es, weil der neue Prozessor (logischerweise) auch das Featureset des älteren unterstützt.
Bei ausgeschalteten VMs geht es deswegen, weil das Gast OS den Prozessor ja erst beim Booten initialisiert und die Features erkennt.
In Clustern würde die Migration auch nur laufen, wenn der neuere Host im Kompatibilitätsmodus läuft. Dadurch würde sein Prozessor künstlich auf das Featureset des alten beschränkt, wodurch eine Live Migration wieder möglich wäre.
Beide von 2023
Der 4110 ist aus 2017 und der 4410Y aus 2023...
Gruß,
Avoton
1
Das verhalten ist sogar nötig... Dein HyperV ist keine Zauberbox und es laufen auch keine magischen Einhörner durch deine Server. Dein HyperV gibt ja den Befehlssatz der CPU an den Gast weiter - und bei der Live-Migration tust du so als würdest du mal eben im Betrieb eines richtigen Rechners auch gleich noch die CPU rausreissen und ne andere einbauen. Ich denke da würdest du auch nicht erwarten das es klappt, oder?
Stell dir halt einfach vor das deine VM ein realer Rechner wäre - nur das der Mainboard-Hersteller jetzt eben "Microsoft" ist. Das ist zwar natürlich grob aber generell schon hilfreich und erklärt dir eben auch anschaulich warum du im Betrieb zB. keinen RAM "hinzufügen" kannst (ausser es war als dynamisch gekennzeichnet),... Und eben auch warum du eben Migrationen nur auf identischer Hardware machen kannst (gerne genommen auch der Fehler ne CD vom lokalen ISO einzubinden und sich zu wundern warum es mit der Migration nich mehr klappt ;) ).
Stell dir halt einfach vor das deine VM ein realer Rechner wäre - nur das der Mainboard-Hersteller jetzt eben "Microsoft" ist. Das ist zwar natürlich grob aber generell schon hilfreich und erklärt dir eben auch anschaulich warum du im Betrieb zB. keinen RAM "hinzufügen" kannst (ausser es war als dynamisch gekennzeichnet),... Und eben auch warum du eben Migrationen nur auf identischer Hardware machen kannst (gerne genommen auch der Fehler ne CD vom lokalen ISO einzubinden und sich zu wundern warum es mit der Migration nich mehr klappt ;) ).
1
Moin @maretz,
natürlich kannst du bei einem Hyper-V einer VM, vorausgesetzt deren Gast-OS unterstützt das auch, im laufenden Betrieb mehr RAM geben und zwar auch ohne, dass der dynamische RAM aktiviert ist.
Und auch dieses Problem lässt sich, zumindest bei einem Cluster umgehen, indem man die entsprechenden ISO's nicht auf die lokalen Datenträger der HV Nodes legt, sondern auf die CSV mit dazu packt. 😉
Und das mit der Livemigration zwischen zwei HV-Nodes mit unterschiedlichen CPU's klappt eigentlich auch, aber nur wenn die Nodes geclustert sind und in der VM Konfig der Kompatibilitätsmodus aktiviert ist.
Die Nodes des TO's sind jedoch höchstwahrscheinlich nicht geclustert, daher tun die auch beim einschalten einer VM deren Kompatibilitätsmodus aktiviert ist, nicht wirklich ihre CPU Konfiguration untereinander abstimmen, da das nur bei einem HV-Cluster geschieht und daher ist das Verhalten was der TO beschreibt, auch ganz normal.
Gruss Alex
und erklärt dir eben auch anschaulich warum du im Betrieb zB. keinen RAM "hinzufügen" kannst (ausser es war als dynamisch gekennzeichnet),...
natürlich kannst du bei einem Hyper-V einer VM, vorausgesetzt deren Gast-OS unterstützt das auch, im laufenden Betrieb mehr RAM geben und zwar auch ohne, dass der dynamische RAM aktiviert ist.
Und eben auch warum du eben Migrationen nur auf identischer Hardware machen kannst (gerne genommen auch der Fehler ne CD vom lokalen ISO einzubinden und sich zu wundern warum es mit der Migration nich mehr klappt ;) ).
Und auch dieses Problem lässt sich, zumindest bei einem Cluster umgehen, indem man die entsprechenden ISO's nicht auf die lokalen Datenträger der HV Nodes legt, sondern auf die CSV mit dazu packt. 😉
Und das mit der Livemigration zwischen zwei HV-Nodes mit unterschiedlichen CPU's klappt eigentlich auch, aber nur wenn die Nodes geclustert sind und in der VM Konfig der Kompatibilitätsmodus aktiviert ist.
Die Nodes des TO's sind jedoch höchstwahrscheinlich nicht geclustert, daher tun die auch beim einschalten einer VM deren Kompatibilitätsmodus aktiviert ist, nicht wirklich ihre CPU Konfiguration untereinander abstimmen, da das nur bei einem HV-Cluster geschieht und daher ist das Verhalten was der TO beschreibt, auch ganz normal.
Gruss Alex
1
Alles klar. Dann war ich da zu blauäugig und hatte angenommen zumindest zwischen Intel CPUs wäre das kein Problem. Aber zumindest verstehe ich jetzt das Problem. Die Hosts sind in keinem Cluster mit geteiltem Storage. Sie sehen sich lediglich im Hyper-V Manager und lassen sich da steuern.
Kann mir aber einer verraten, was der technische Hintergrund ist, dass ich VMs dann trotzdem im ausgeschalteten Zustand ohne Probleme von neu auf alt migrieren kann, obwohl der Komptibilitätsmodus deaktiviert ist? Werden da dann gewisse Eigenschaften in der VM angepasst, welche im angeschalteten Zustand nicht gehen? Ich müsste ja dann davon ausgehen, dass nach solch einer Migration immer das vollständige, verfügbare Featureset des Hosts abgebildet wird, richtig?
Gruß
Kann mir aber einer verraten, was der technische Hintergrund ist, dass ich VMs dann trotzdem im ausgeschalteten Zustand ohne Probleme von neu auf alt migrieren kann, obwohl der Komptibilitätsmodus deaktiviert ist? Werden da dann gewisse Eigenschaften in der VM angepasst, welche im angeschalteten Zustand nicht gehen? Ich müsste ja dann davon ausgehen, dass nach solch einer Migration immer das vollständige, verfügbare Featureset des Hosts abgebildet wird, richtig?
Gruß
Die Hyper-Vs sind auch 2022er Server?
Ich hatte bei einen Kunden mal das Thema, das in seinen 2012er Cluster keine Live Migration von 2019er Server möglich war, unterstützt wurde nur bis 2016er.
Ich hatte bei einen Kunden mal das Thema, das in seinen 2012er Cluster keine Live Migration von 2019er Server möglich war, unterstützt wurde nur bis 2016er.
Zitat von @WoenK0:
Die Hyper-Vs sind auch 2022er Server?
Ich hatte bei einen Kunden mal das Thema, das in seinen 2012er Cluster keine Live Migration von 2019er Server möglich war, unterstützt wurde nur bis 2016er.
Die Hyper-Vs sind auch 2022er Server?
Ich hatte bei einen Kunden mal das Thema, das in seinen 2012er Cluster keine Live Migration von 2019er Server möglich war, unterstützt wurde nur bis 2016er.
Ja, beides 2022er.
Kann mir aber einer verraten, was der technische Hintergrund ist, dass ich VMs dann trotzdem im ausgeschalteten Zustand ohne Probleme von neu auf alt migrieren kann, obwohl der Komptibilitätsmodus deaktiviert ist?
Hab ich doch oben geschrieben.
Die VM initialisiert die CPU erst beim Boot und erkennt dabei das andere Featureset. Das geht aber bei einer Live Migration nicht, da die VM das ja gar nicht merkt, dass sie migriert wird und auf einmal taucht dann eine völlig andere CPU auf...
Du kannst auch bei physischen PCs die Platte umbauen und Windows bootet in der Regel ohne größere Probleme.
Das würde ja sonst auch nicht gehen ;)
Gruß,
Avoton
2Zitat von @Avoton:
Hab ich doch oben geschrieben.
Die VM initialisiert die CPU erst beim Boot und erkennt dabei das andere Featureset. Das geht aber bei einer Live Migration nicht, da die VM das ja gar nicht merkt, dass sie migriert wird und auf einmal taucht dann eine völlig andere CPU auf...
Du kannst auch bei physischen PCs die Platte umbauen und Windows bootet in der Regel ohne größere Probleme.
Das würde ja sonst auch nicht gehen ;)
Gruß,
Avoton
Kann mir aber einer verraten, was der technische Hintergrund ist, dass ich VMs dann trotzdem im ausgeschalteten Zustand ohne Probleme von neu auf alt migrieren kann, obwohl der Komptibilitätsmodus deaktiviert ist?
Hab ich doch oben geschrieben.
Die VM initialisiert die CPU erst beim Boot und erkennt dabei das andere Featureset. Das geht aber bei einer Live Migration nicht, da die VM das ja gar nicht merkt, dass sie migriert wird und auf einmal taucht dann eine völlig andere CPU auf...
Du kannst auch bei physischen PCs die Platte umbauen und Windows bootet in der Regel ohne größere Probleme.
Das würde ja sonst auch nicht gehen ;)
Gruß,
Avoton
Ah, verstehe. Stand ich auf dem Schlauch. Jetzt hab ich es kapiert. Vielen Dank
