13
LiveMigration Hyper-V 2022 zu Hyper-V 2019 (VM-VERSIONEN)
Hallo zusammen,
ich beschäftige mich gerade mit der Hyper-V Livemigration von Windows Server 2019 zu Windows Server 2022.
NUR ZUM LERNEN; KEINE PRODUKTIV SYSTEME
Das funktionierte Out of the Box leider nicht weil die VM Version auf dem 2022 10.0 ist und der 2019 nur bis 9.0 unterstützt.
Ich kann aber ja auf dem 2022 eine neue VM mit der Version 9.0 erstellen und die VHDX dort einbinden. Somit könnte ich alle Server die VM-Version 10.0 haben per LiveMigration auf den 2019 Host verschieben.
Interessiert die Server sowas?
Speziell ein DC oder ein Exchange?
Kann es zu Problemen kommen in einer Produktiv Umgebung?
Für das KnowHow: Wäre das also eine alternative statt Copy&Paste der Daten oder Export/Import?
Danke schonmal
ich beschäftige mich gerade mit der Hyper-V Livemigration von Windows Server 2019 zu Windows Server 2022.
NUR ZUM LERNEN; KEINE PRODUKTIV SYSTEME
Das funktionierte Out of the Box leider nicht weil die VM Version auf dem 2022 10.0 ist und der 2019 nur bis 9.0 unterstützt.
Ich kann aber ja auf dem 2022 eine neue VM mit der Version 9.0 erstellen und die VHDX dort einbinden. Somit könnte ich alle Server die VM-Version 10.0 haben per LiveMigration auf den 2019 Host verschieben.
Interessiert die Server sowas?
Speziell ein DC oder ein Exchange?
Kann es zu Problemen kommen in einer Produktiv Umgebung?
Für das KnowHow: Wäre das also eine alternative statt Copy&Paste der Daten oder Export/Import?
Danke schonmal
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: 670146
Url: https://administrator.de/contentid/670146
Ausgedruckt am: 12.12.2024 um 16:12 Uhr
13 Kommentare
Neuester Kommentar
Moin.
Dann sollte deine Überschrift aber anders lauten:
Hyper-V 2019 nach Hyper-V 2022
Ich hatte das genauso wie du beschreibst von 2016 nach 2019 gemacht, d.h. neue VM erstellen und die VHDX nutzen. Hab damit keine Probleme.
Soll heißen ich würde es in deinem Fall mal mit ein paar gesicherten, unkritischen Systemen laufen lassen.
Dann sollte deine Überschrift aber anders lauten:
Hyper-V 2019 nach Hyper-V 2022
Ich hatte das genauso wie du beschreibst von 2016 nach 2019 gemacht, d.h. neue VM erstellen und die VHDX nutzen. Hab damit keine Probleme.
Soll heißen ich würde es in deinem Fall mal mit ein paar gesicherten, unkritischen Systemen laufen lassen.
Moin,
warum will man denn VMs von 2022 zu 2019 migrieren?
Ziehe den 2019er hoch oder bleibe in der für 2019 supporteten VM-Version
warum will man denn VMs von 2022 zu 2019 migrieren?
Ziehe den 2019er hoch oder bleibe in der für 2019 supporteten VM-Version
Ne die soll genau so heißen, Quasi ein Downgrade der VM Version 10.0 auf 9.0. Also VM´s vom Hyper-V Host 2022 zu Hyper-V Host 2019 verschieben.
Zitat von @em-pie:
Moin,
warum will man denn VMs von 2022 zu 2019 migrieren?
Ziehe den 2019er hoch oder bleibe in der für 2019 supporteten VM-Version
Moin,
warum will man denn VMs von 2022 zu 2019 migrieren?
Ziehe den 2019er hoch oder bleibe in der für 2019 supporteten VM-Version
Der 2019 kann kein 2022. Ich hab hier ein Steinaltes Board, ich bekomme kein 2022 installiert.
Wenn du die VHDX in eine neue VM packst, ändert sich die Netzwerkkonfiguration. Beim DC würde ich da aufpassen. Wenn es eine Produktivumgebung ist, bleib lieber sauber und bringe alle auf einen gemeinsamen Nenner.
1
Moin.
Wie du schon beschreibst, kann 2019 (v9) keine 2022 (v10) per Live-Migration
Und die frage
dürfte wohl so selten mit einem in der Produktion trifftigen Grund beantwortet werden, das da wohl keiner eine Lösung bietet.
Du könntest dir ein Powershell-Skript schreiben (lassen), das auf dem 2022 eine v9-VM erstellt...
... aber dann auch eines, das selbiges auf dem 2019er macht ...
Stichwort: PSRemote
Wie du schon beschreibst, kann 2019 (v9) keine 2022 (v10) per Live-Migration
Und die frage
warum will man denn VMs von 2022 zu 2019 migrieren?
dürfte wohl so selten mit einem in der Produktion trifftigen Grund beantwortet werden, das da wohl keiner eine Lösung bietet.
Du könntest dir ein Powershell-Skript schreiben (lassen), das auf dem 2022 eine v9-VM erstellt...
... aber dann auch eines, das selbiges auf dem 2019er macht ...
Stichwort: PSRemote
Zitat von @MirkoKR:
Moin.
Wie du schon beschreibst, kann 2019 (v9) keine 2022 (v10) per Live-Migration
Und die frage
dürfte wohl so selten mit einem in der Produktion trifftigen Grund beantwortet werden, das da wohl keiner eine Lösung bietet.
Du könntest dir ein Powershell-Skript schreiben (lassen), das auf dem 2022 eine v9-VM erstellt...
... aber dann auch eines, das selbiges auf dem 2019er macht ...
Stichwort: PSRemote
Moin.
Wie du schon beschreibst, kann 2019 (v9) keine 2022 (v10) per Live-Migration
Und die frage
warum will man denn VMs von 2022 zu 2019 migrieren?
dürfte wohl so selten mit einem in der Produktion trifftigen Grund beantwortet werden, das da wohl keiner eine Lösung bietet.
Du könntest dir ein Powershell-Skript schreiben (lassen), das auf dem 2022 eine v9-VM erstellt...
... aber dann auch eines, das selbiges auf dem 2019er macht ...
Stichwort: PSRemote
Ich habs doch hinbekommen (im Thema beschrieben. LiveMigration funktioniert damit.), meine Frage ist ob ein DC oder Exchange bei sowas meckert.
Sinn oder Unsinn sei mal dahin gestellt.
Ich suche Erfahrung, vielleicht hat jemand ja genau so einen Fall.
Zitat von @NordicMike:
Wenn du die VHDX in eine neue VM packst, ändert sich die Netzwerkkonfiguration. Beim DC würde ich da aufpassen. Wenn es eine Produktivumgebung ist, bleib lieber sauber und bringe alle auf einen gemeinsamen Nenner.
Wenn du die VHDX in eine neue VM packst, ändert sich die Netzwerkkonfiguration. Beim DC würde ich da aufpassen. Wenn es eine Produktivumgebung ist, bleib lieber sauber und bringe alle auf einen gemeinsamen Nenner.
DC ist schnell neu gemacht, kein Problem. Aber was ist mit nem Exchange, der ist nicht so schnell neu gemacht.
Kannst du genauer definieren was du mit Netzwerkkonfiguration meinst bzw. warum du sorge hast das ein DC das nicht verträgt?
Zitat von @i4mr00t:
Ich habs doch hinbekommen (im Thema beschrieben. LiveMigration funktioniert damit.), meine Frage ist ob ein DC oder Exchange bei sowas meckert.
Ich habs doch hinbekommen (im Thema beschrieben. LiveMigration funktioniert damit.), meine Frage ist ob ein DC oder Exchange bei sowas meckert.
Falls du fragst ob EX oder DC ein Problem mit der älteren VM Version haben lautet die Antwort nein, das ist problemfrei.
/Thomas
1Zitat von @i4mr00t:
Ne die soll genau so heißen, Quasi ein Downgrade der VM Version 10.0 auf 9.0. Also VM´s vom Hyper-V Host 2022 zu Hyper-V Host 2019 verschieben.
Auch das hatte ich in einer Umgebung problemlos gemacht, von 2019 nach 2016.Ne die soll genau so heißen, Quasi ein Downgrade der VM Version 10.0 auf 9.0. Also VM´s vom Hyper-V Host 2022 zu Hyper-V Host 2019 verschieben.
Warum?
90% der Datacenter sind dort WS016, beim Restore hätte man sonst den Host nicht frei wählen können, also alles auf die gleiche Version, war dann Hyper-V 9.0 zu 8.0.
Kannst du genauer definieren was du mit Netzwerkkonfiguration meinst bzw. warum du sorge hast das ein DC das nicht verträgt?
Die Schnittstelle ändert sich, dadurch verlierst du erst einmal die fest eingestellten IP Adressen und das OS geht mit der neuen Netzwerkschnittstelle auf DHCP. Man muss dann alles wieder einstellen. Die Dienste spielen dabei alle verrückt. Einmal eingestellt und neu gebootet klappt es dann wieder. Wenn man dann wieder zurück migriert, merkt das OS, dass die Netzwerkschnittstelle bereits existiert und er möchte die alte Konfiguration verwenden. Dabei kommt eine Meldung, dass die IP Adresse bereits einer andere Schnittstelle zugewiesen ist und man beginnt wieder alles neu einzustellen. Man muss dafür die ausgeblendeten inaktiven Netzwerkschnittstellen einblenden und deren IP Adresse entfernen. Also wieder alles neu konfigurieren. Die Idee einer Live Migration ist auf jeden Fall sowieso nicht mehr gegeben. Spätestens nach ein paar Migrationen kracht es dann auch mal ordentlich. Also wäre es OK für eine einmalige Wartungs-Sache, aber nicht im Sinne einer Live Migration.
Zitat von @nachgefragt:
Warum?
90% der Datacenter sind dort WS016, beim Restore hätte man sonst den Host nicht frei wählen können, also alles auf die gleiche Version, war dann Hyper-V 9.0 zu 8.0.
Zitat von @i4mr00t:
Ne die soll genau so heißen, Quasi ein Downgrade der VM Version 10.0 auf 9.0. Also VM´s vom Hyper-V Host 2022 zu Hyper-V Host 2019 verschieben.
Auch das hatte ich in einer Umgebung problemlos gemacht, von 2019 nach 2016.Ne die soll genau so heißen, Quasi ein Downgrade der VM Version 10.0 auf 9.0. Also VM´s vom Hyper-V Host 2022 zu Hyper-V Host 2019 verschieben.
Warum?
90% der Datacenter sind dort WS016, beim Restore hätte man sonst den Host nicht frei wählen können, also alles auf die gleiche Version, war dann Hyper-V 9.0 zu 8.0.
Die Antwort freut mich sehr! waren auch DC oder EX dabei?
Zitat von @NordicMike:
Die Schnittstelle ändert sich, dadurch verlierst du erst einmal die fest eingestellten IP Adressen und das OS geht mit der neuen Netzwerkschnittstelle auf DHCP. Man muss dann alles wieder einstellen. Die Dienste spielen dabei alle verrückt. Einmal eingestellt und neu gebootet klappt es dann wieder. Wenn man dann wieder zurück migriert, merkt das OS, dass die Netzwerkschnittstelle bereits existiert und er möchte die alte Konfiguration verwenden. Dabei kommt eine Meldung, dass die IP Adresse bereits einer andere Schnittstelle zugewiesen ist und man beginnt wieder alles neu einzustellen. Man muss dafür die ausgeblendeten inaktiven Netzwerkschnittstellen einblenden und deren IP Adresse entfernen. Also wieder alles neu konfigurieren. Die Idee einer Live Migration ist auf jeden Fall sowieso nicht mehr gegeben. Spätestens nach ein paar Migrationen kracht es dann auch mal ordentlich. Also wäre es OK für eine einmalige Wartungs-Sache, aber nicht im Sinne einer Live Migration.
Kannst du genauer definieren was du mit Netzwerkkonfiguration meinst bzw. warum du sorge hast das ein DC das nicht verträgt?
Die Schnittstelle ändert sich, dadurch verlierst du erst einmal die fest eingestellten IP Adressen und das OS geht mit der neuen Netzwerkschnittstelle auf DHCP. Man muss dann alles wieder einstellen. Die Dienste spielen dabei alle verrückt. Einmal eingestellt und neu gebootet klappt es dann wieder. Wenn man dann wieder zurück migriert, merkt das OS, dass die Netzwerkschnittstelle bereits existiert und er möchte die alte Konfiguration verwenden. Dabei kommt eine Meldung, dass die IP Adresse bereits einer andere Schnittstelle zugewiesen ist und man beginnt wieder alles neu einzustellen. Man muss dafür die ausgeblendeten inaktiven Netzwerkschnittstellen einblenden und deren IP Adresse entfernen. Also wieder alles neu konfigurieren. Die Idee einer Live Migration ist auf jeden Fall sowieso nicht mehr gegeben. Spätestens nach ein paar Migrationen kracht es dann auch mal ordentlich. Also wäre es OK für eine einmalige Wartungs-Sache, aber nicht im Sinne einer Live Migration.
Danke für die ausführlichere Antwort.
Wir gehen mal nur von einer einmaligen Migration aus.
