[TUTORIAL] Kleiner Gamechanger bei der Windows Migration zu Proxmox

[Falk R.]

Da ja schon die Methode zur Migration mit minimaler Downtime auf meinem Mist gewachsen ist, habe ich heute weitere gute Neuigkeiten.
Es ist möglich die Virtio Treiber vorab zu installieren, so das Windows direkt nach der Migration von VirtIO SCSI booten kann. Um es allen etwas leichter zu machen, habe ich ein virtio ISO modifiziert und da eine installations-Batchdatei abgelegt.
Bitte beachten, die Batchdatei muss im Pfad des CD Laufwerks als Administrator ausgeführt werden.

Download

Eventuell hat jemand mit Programmiererfahrung ja Lust, aus der Batchdatei einen richtigen Installer zu bauen.

 

[ThoSo]

Wenn ich die Batch richtig gelesen habe installiert diesen den Passenden Treiber und macht den Scharf ohne das die VM unter einem ESXi Host jemals so eine Festplatte gesehen hat!
Cool und das noch mit der neusten 271er !

 

[Falk R.]

Ja, genau das macht er. Habe heute auf einem Win2008R2 testen können, der wurde leider als Win7 erkannt, aber funktioniert trotzdem wunderbar.

 

[aaron]

Hi Falk!
Ich hab mir das mal angesehen. Das devcon Tool erstellt, soweit ich das sehe, dann das Dummy Device.
Da devcon nicht immer installiert wird, hab ich mal nachgesehen und MS empfiehlt selber doch lieber pnputil zu verwenden. https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-install

In dem Beispiel als Ersatz wird dann zuerst das Device mit devgen erstellt. Das Tool ist leider auch nicht von Haus aus installiert.

MS Binaries innerhalb der VirtIO ISO ausliefern wird Lizenztechnisch wahrscheinlich interessant, wenn man das Upstream einbringen will. ;-)

Wir sehen uns mal Upstream an ob man da im Installprozess nicht was machen kann um vlt automatisch ein Dummy Device mit der richtigen HW ID kurz einzuhängen.

Der Ansatz an sich ist soweit ganz nett

Danke für die Arbeit!

 

[Falk R.]

Hi Falk!
Ich hab mir das mal angesehen. Das devcon Tool erstellt, soweit ich das sehe, dann das Dummy Device.
Da devcon nicht immer installiert wird, hab ich mal nachgesehen und MS empfiehlt selber doch lieber pnputil zu verwenden. https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-install

In dem Beispiel als Ersatz wird dann zuerst das Device mit devgen erstellt. Das Tool ist leider auch nicht von Haus aus installiert.

MS Binaries innerhalb der VirtIO ISO ausliefern wird Lizenztechnisch wahrscheinlich interessant, wenn man das Upstream einbringen will. ;-)

Wir sehen uns mal Upstream an ob man da im Installprozess nicht was machen kann um vlt automatisch ein Dummy Device mit der richtigen HW ID kurz einzuhängen.

Der Ansatz an sich ist soweit ganz nett

Danke für die Arbeit!

Hi Aaron,
mit pnputil habe ich das nicht bootfähig hinbekommen. Devcon trägt stumpf die HW ID ein, auch wenn das Gerät nicht vorhanden ist.
Ich habe deshalb erst einmal eine Modifizierte ISO erstellt zum Heimgebrauch.
Wenn du weißt wie man ein Dummydevice im Windows erzeugen kann, dann wäre das natürlich noch einfacher und der normale Installationsprozess würde dann alles übernehmen.

 

[aaron]

mit pnputil habe ich das nicht bootfähig hinbekommen.

ja, ich habs nicht ausprobiert, aber der von mir verlinkten Seite zu devcon ist folgendes als Ersatz vorgeschlagen:

devgen /add /bus ROOT /hardwareid HardwareID
pnputil /add-driver INFfile /install

Aber devgen ist leider auch etwas das man extra runterladen muss. Ich kenn mich ad-hoc zu wenig aus, aber evtl. kann man im Rahmen des Installers direkt über die Windows API das dummy device auch anlegen und entfernen, ohne auf Tools zurückgreifen zu müssen.

 

[ThoSo]

Ich finde die Idee mit der Batch eigentlich gut. Sie kann von jedermann an neue Build-Nummern angepasst werden, wenn er das Beispielsweise mit Insider Versionen testen möchte. Zumindest ist das transparent (kann jeder lesen, verstehen oder auch nicht ) und nicht in einer EXE eingebaut.
My2Cent!

 

[TErxleben]

Verstehe ich nicht ganz. Wo ist Vorteil ggü.:

• auf der zu migrierenden Maschine die Virtio-Treiber wie gewohnt installieren.
• Maschine migrieren, starten und herunterfahren
• Einstellungen in PVE anpassen.
• Maschine neu starten.

??

 

[Falk R.]

Verstehe ich nicht ganz. Wo ist Vorteil ggü.:

• auf der zu migrierenden Maschine die Virtio-Treiber wie gewohnt installieren.
• Maschine migrieren, starten und herunterfahren
• Einstellungen in PVE anpassen.
• Maschine neu starten.

??

Migrationen mit minimaler Downtime, wie z.B. im Gesundheitssektor.
Im Krankenhaus laufen diverse Systeme 24x7x365 und da versucht man die Downtime zu minimieren.
Wenn du den Treiber bereits vorher bootfähig drin hast, per diskpart die Platten nach dem wechsel auch wieder automatisch online nehmen lassen und die IP direkt wieder per DHCP zu geben, verkürzt die Downtime auf einen Reboot, was je nach OS mal gerade 1-2 Minuten sind.
Damit stört man den Betrieb deutlich weniger und kann verhindern, dass diese Krankenhaus sich von der Notfallversorgung abmelden muss.

 

[TErxleben]

Die Downtime resultiert doch eher aus der eigentlichen Migration.
Die ein, zwei nachträglichen Handgriffe sind doch eher zu vernachlässigen.
Was übersehe ich?

 

[aaron]

Was übersehe ich?

Wenn man die manuellere Variante via network share nimmt (https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Manual_Migration auf @Falk R. 's Mist gewachsen ) dann spart das deutlich zeit, weil man die neue VM auf Proxmox VE Seite gleich final mit VirtIO SCSI Disks konfigurieren kann und sich den Tanz mit Dummy Disk und mehreren Reboots spart. Somit ists dann wirklich nur der shutdown der Source VM → Start der neuen VM auf Proxmox VE → MoveDisk zum Ziel Storage während die VM ihre Dienste leistet.

 

[Falk R.]

Die Downtime resultiert doch eher aus der eigentlichen Migration.
Die ein, zwei nachträglichen Handgriffe sind doch eher zu vernachlässigen.
Was übersehe ich?

Wie Aaron richtig geschrieben hat und kleiner Tipp von mir, mal die Offizielle Doku im Wiki lesen. Da stehen viele interessante Dinge drin.

 

[TErxleben]

Nichts gegen dein Vorgehen, sondern u.U. durchaus hilfreich um eine VM im laufenden Betrieb zu migrieren. Aber das ist in meinen Augen eher ein Nischenproblem. Ich habe die Anforderung schlicht nicht und habe deshalb nachgefragt.
Wenn ich dich, aus der von mir ja eigentlich ignorierten Original-Doku, zitieren darf:

If the source VM is accessible by both the VMware and Proxmox VE clusters (ideally via a network share), Proxmox VE can use the *.vmdk disk image to start the VM right away. Then, the disk image can be moved to the final target storage in the Proxmox VE cluster while the VM is running. The resulting downtime will be minimal. This method is more involved than the other methods, but the very short downtime can be worth it.

Wir virtualisieren eher Baremetal oder VMs aus den unterschiedlichsten Quellen.
Da ist jeder Jeck anders und ich klebe da ungern ein zu pflegendes Script dran. Die technischen Voraussetzungen gibt es schlechterdings auch nicht. Der Bedarf ist einfach nicht da.
Trotzdem Hut ab vor deiner Lösung, vielleicht fällt mir mal der Bedarf auf die Füsse.

 

[Falk R.]

Nichts gegen dein Vorgehen, sondern u.U. durchaus hilfreich um eine VM im laufenden Betrieb zu migrieren. Aber das ist in meinen Augen eher ein Nischenproblem. Ich habe die Anforderung schlicht nicht und habe deshalb nachgefragt.
Wenn ich dich, aus der von mir ja eigentlich ignorierten Original-Doku, zitieren darf:

Wir virtualisieren eher Baremetal oder VMs aus den unterschiedlichsten Quellen.
Da ist jeder Jeck anders und ich klebe da ungern ein zu pflegendes Script dran. Die technischen Voraussetzungen gibt es schlechterdings auch nicht. Der Bedarf ist einfach nicht da.
Trotzdem Hut ab vor deiner Lösung, vielleicht fällt mir mal der Bedarf auf die Füsse.

Dann lebst du in einer ganz anderen Welt als ich und ganz viele Mittelständische Unternehmen in Deutschland.
Die Migrationsmethode nutze ich jede Woche unzählige Male und habe schon über 1000VMs so migriert. Es gibt viele Unternehmen und Einrichtungen, welche keine langen Downtime Zeiten haben. Außerdem will man ja nicht jedes Wochenende arbeiten.

 

[TErxleben]

So ist es offenbar. Der berühmte KMU (10-250 MA) liegt hier eher bei 10 als bei 250 (und z.T sogar darunter).
Da werden i.d.R Server migriert und Arbeitsstationen als VM sauber neu aufgesetzt.
Da bringt ein Automatismus einfach nichts.
So häufig migriert man ja nun auch nicht. Jedenfalls bei uns.

 

[fba]

pnputil /add-driver INFfile /install

Das hatte ich vor einiger Zeit auch mal probiert, aber der Treiber landet dann nicht bei den für den Boot relevanten. pnputil erzeugt anscheinend keinen devnode im Gegensatz zu devcon. Damit wird der Treiber leider nie installiert und als relevant für den Boot eingestuft. Deswegen bevorzuge ich aktuell diese Methode via dism.

Zum Thema "Dummy Device": man kann mit der Win32-API und SwCreateDevice einen devnode anlegen, der maximal bis zum Reboot existiert (Doku).
Wer's kompilieren, linken und testen möchte: angehängt ist ein Beispiel in C. Wahrscheinlich muss man vorher die virtio-Treiber installieren, den devnode erzeugen und dann noch pnputil /scan-devices laufen lassen, damit das Gerät erkannt und die Treiber installiert werden.