ja hab auch gerade gelesen das es überwiegend 2025 und w11 betrifft. Gut das wir 2019 und 2022 fahren
Danke![TUTORIAL] Kleiner Gamechanger bei der Windows Migration zu Proxmox
- Thread starter Falk R.
- Start date
Danke!
Wäre jetzt schön gewesen, wenn man mal das Hauptverzeichnis der DVD gesehen hätte und auch ob das Script von der DVD aus gestartet wurde.
Das wurde natürlich gemacht und hatte bei meinen Tests bisher auch immer funktioniert, indem man das .BAT einfach doppelklickt und fertig.
Dann hast du das jetzt falsch verstanden, den die fehlermeldung das er die devcon.exe nicht findet, kann ja bedeuten, das sie nicht drauf ist - daher die frage.
Es ist die ISO aus dem ersten Beitrag, eingebunden in der VM, direkt das bat gestartet vom CD-Laufwerk aus.
Hab das gerade mal getestet - ich kann den Fehler mit der ersten CD von Falk leider nicht nachvollziehen.
Ist auf der Installation in den Umgebungsvariablen etwas anders?
Am Laufwerksbuchstaben liegt es nicht (E: und Z: getestet)
Funktioniert das ganze, wenn du es mit einer Eingabeaufforderung von CD direkt startest?
Du darfst das Script nicht per Klick starten, außer bei 2022+. Immer eine CMD oder PS mit dem Pfad der CD aufmachen und da ausführen. Ein auslesen des CD Laufwerks scheitert leider, wenn mehrere Laufwerke vorhanden sind. Wenn jemand einen guten Tipp dafür hat, kann man das Script gern anpassen.
Funktioniert das auch mit einen Ceph-Storage bei Proxmox?
Hier konnte ich dazu ein altes Video finden
https://www.youtube.com/watch?v=8mQVBDYmjnY
Die Methode von Falk (der ja auch die von dir verlinkte Präsentation gehalten hat) sollte grundsätzlich mit allen Netzwerkspeichern funktionieren, die vom alten und neuen Hypervisor unterstüzt werden. Nun wird Ceph von vmware ja nicht unterstützt, aber du könntest z.B. eine VM in deiner ProxmoxVE-Umgebung einrichten, die eine NFS-Freigabe bereitstellt und die Daten selbst in Ceph ablegt. Ist halt am Ende ein bisschen mehr Geklicke, um die dort gespeicherten *vmdk-Dateien in das endgültige Zielstorage (ceph blockspeicher) zu verschieben.
Das ist mir klar und ja, das funktioniert mit Falks Methode, braucht halt eine Netzwerkfreigabe als "Zwischenlager".Die Frage ist, wie man große VMs von vCenter-Cluster mit minimaler downtime zu einem PVE-Ceph-Cluster migrieren kann
So wie ich es jeden Monat mehrfach mache.Die Frage ist, wie man große VMs von vCenter-Cluster mit minimaler downtime zu einem PVE-Ceph-Cluster migrieren kann
Irgendwo brauchst du einen temporären NFS Speicher. Entweder habe ich viele SSDs und kann Ceph ein paar vorenthalten, dann baue ich schnell einen ZFS Pool von dem ich einen NFS Speicher für vSphere bereitstelle. Nach der Migration wird der ZFS Pool gekillt und die SSDs dem Ceph hinzugefügt.
Alternativ geht auch ein externer Server oder ein altes Storage, welches NFS bereitstellen kann.
Ich habe auch schon einen für PBS vorgesehenen Server mit vielen NVMe's dafür genutzt, bevor er danach zum PBS geworden ist.
Eine alte NetApp aus der Rümpelkammer hilft auch.
Es gibt viele Möglichkeiten, aber du brauchtst unbedingt einen Speicher der von vSphere unterstützt wird und auch von anderen System genutzt werden kann, also alles ohne VMFS. Da bleibt bei vSphere leider nur NFS übrig.
Last edited:
Ok. Den NFS-Speicher stelle ich dann Proxmox und vSphere bereit. Von vSphere kopiere ich dich vmdk auf den Speicher und importiere diese dann über die CLI in Proxmox? Habe da ich weniger Downtime, wenn ich den esxi importer von Proxmox nehmen würde?
So wie von Falk im Video und in folgender Anleitung beschrieben:
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime)
Frage nach wenn was unklar ist, aber ich werde jetzt nicht das hier vollständig reinkopieren
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime)
Frage nach wenn was unklar ist, aber ich werde jetzt nicht das hier vollständig reinkopieren
Du gibst der Proxmox VM den zugriff auf die gleiche VMDK wie der vSphere VM. Deshalb kann man die auf vSphere einfach runter fahren und direkt auf Proxmox booten. Natürlich mit allen vor und Nachteilen. Schaltest du aus versehen beide zeitgleich ein, hast du nur noch Datenmüll auf der Disk.
Also immer auf Nummer sicher gehen. Wenn du dir unsicher bist, besuche eine Schulung oder beauftrage einen Dienstleister, der das schon öfters gemacht hat.
@Falk R.,
gute Zusammenfassung
@sala82 Ergänzend dazu: Der Importer kopiert/synct die Daten vor (oder während) dem Start, was IO-Last erzeugt und Zeit kostet. Die NFS-Methode mountet die existierende Disk sofort (Mapping). Du hast also keine Wartezeit für den Kopiervorgang, sondern startest direkt und nutzt die Proxmox Live Storage Migration im Hintergrund.
@jsterr Dein Screenshot bestätigt Falks Vermutung: Die CMD steht auf. Du musst in der CMD erst auf das Laufwerk wechseln (z. B. via
gute Zusammenfassung
@sala82 Ergänzend dazu: Der Importer kopiert/synct die Daten vor (oder während) dem Start, was IO-Last erzeugt und Zeit kostet. Die NFS-Methode mountet die existierende Disk sofort (Mapping). Du hast also keine Wartezeit für den Kopiervorgang, sondern startest direkt und nutzt die Proxmox Live Storage Migration im Hintergrund.
@jsterr Dein Screenshot bestätigt Falks Vermutung: Die CMD steht auf
C:\Windows\System32. Die devcon.exe liegt aber auf der CD (Z. Du musst in der CMD erst auf das Laufwerk wechseln (z. B. via cd /d Z:), damit das Skript die Datei im aktuellen Verzeichnis findet.Hallo in die Runde,
ich wünsche allen ein frohes neues Jahr in der Community
Ich habe vor einiger Zeit bereits mit Proxmox experimentiert und mir darauf aufbauend auch ein Homelab-Cluster und co. eingerichtet und darüber bereits erste Erfahrungen mit Proxmox sammeln können, allerdings spielt bei mir auch der Open-Source Gedanke eine Rolle, weswegen ich es im Zusammenhang mit Windows und co. zuvor nur peripher im beruflichen Kontext zu tun hatte und nun bei einem Unternehmen
angefangen habe welches komplett dabei ist gänzlich weg von Hyper-V auf Proxmox zu migrieren.
Da ich nun zum leidtragenden geworden bin, mitten in der Umstellung und im Unternehmen sehr stark auf KI zur Wissensfindung gesetzt wird, teilweise vermehrt ohne kritische Hinterfragung (mit teils möglichen katastrophalen Auswirkungen) und ich mich hierdurch durch unzählige Beiträge wühlen musste, ist es mittlerweile soweit das ich mein Wochenende nutze.
Langer Rede kurzer Sinn, es gilt mehrere Hyper-V VMs (WinServer 2019&2022) zu migrieren und auch hier kommt das genannte Problem der SCSI-bedingten "INACCESSIBLE_BOOT_DEVICE" Problematik zum tragen.
So wie ich mittlerweile verstanden habe, geht das darauf zurück das Windows selbst bei vorheriger Installation der VirtIO-Tools/Treiber diese während des Boot-Vorganges nicht lädt, weil das Device ja in der Form nie vorhanden gewesen ist.
Die modifizierten Tools von @Falk R. sorgen nun mittels dem anlegen eines SCSI-Dummys dafür, das die VM selbst bei vorherigem Attachement als SATA0 in Proxmox (dann bootet es ja) dafür, dass bei der Umstellung zurück auf VirtIO SCSI SIngle, dass die Treiber auch zum Boot-Prozess vorhanden sind und WIndows Server starten kann.
Sofern ich das richtig sehe, besser noch(!), bereits vor dem Export aus Hyper-V in der VM vorbereitend installiert werden und direkt als SCSI-Disk von Proxmox starten kann, nachdem der Transfer der Hyper-V ".vhdx" auf das Proxmox-Storage erfolgt ist?
Falls dem so sei, dann ist es die Lösung auf ein Problem, welches wie ich aus eigener Erfahrung sagen kann, nicht nur im Gesundheitssektor(24/7) für sehr viel Erleichterung, sondern auch bei vielen Systemintegratoren/Sysadmins in KMU-Unternehmen mit aktiver Produktion für viele privat für das berufliche genutzten Stunden sorgt.
@Falk R.
Was ich hieraus für meinen Task mitnehme ist, dass ich bestenfalls bereits im Vorfeld mit deinem Script die VirtIO-Tools auf der zu migrierenden Hyper-V VM installiere, dann die .vhdx rüber transferiere und dort das Diskimage per "qm importdisk" importiere und bestenfalls dann eine direkt startende Windows Server-VM in dem Bruchteil der Zeit lauffähig zu haben?
Da mir noch nicht ganz klar ist, welches Format am sinnvollsten ist, die Frage meinerseits ob qcow2 oder raw, da in vielen Anleitungen noch ein Zwischenschritt genannt wird, mit "qemu-img convert" den es nicht eigentlich nicht mehr Bedarf bzw. als Parameter bei qm importdisk mitgegeben werden kann?
Viele Grüße und noch größeren Dank an dich und die Proxmox Community
#wissenschwamm
ich wünsche allen ein frohes neues Jahr in der Community
Ich habe vor einiger Zeit bereits mit Proxmox experimentiert und mir darauf aufbauend auch ein Homelab-Cluster und co. eingerichtet und darüber bereits erste Erfahrungen mit Proxmox sammeln können, allerdings spielt bei mir auch der Open-Source Gedanke eine Rolle, weswegen ich es im Zusammenhang mit Windows und co. zuvor nur peripher im beruflichen Kontext zu tun hatte und nun bei einem Unternehmen
angefangen habe welches komplett dabei ist gänzlich weg von Hyper-V auf Proxmox zu migrieren.
Da ich nun zum leidtragenden geworden bin, mitten in der Umstellung und im Unternehmen sehr stark auf KI zur Wissensfindung gesetzt wird, teilweise vermehrt ohne kritische Hinterfragung (mit teils möglichen katastrophalen Auswirkungen) und ich mich hierdurch durch unzählige Beiträge wühlen musste, ist es mittlerweile soweit das ich mein Wochenende nutze.
Langer Rede kurzer Sinn, es gilt mehrere Hyper-V VMs (WinServer 2019&2022) zu migrieren und auch hier kommt das genannte Problem der SCSI-bedingten "INACCESSIBLE_BOOT_DEVICE" Problematik zum tragen.
So wie ich mittlerweile verstanden habe, geht das darauf zurück das Windows selbst bei vorheriger Installation der VirtIO-Tools/Treiber diese während des Boot-Vorganges nicht lädt, weil das Device ja in der Form nie vorhanden gewesen ist.
Die modifizierten Tools von @Falk R. sorgen nun mittels dem anlegen eines SCSI-Dummys dafür, das die VM selbst bei vorherigem Attachement als SATA0 in Proxmox (dann bootet es ja) dafür, dass bei der Umstellung zurück auf VirtIO SCSI SIngle, dass die Treiber auch zum Boot-Prozess vorhanden sind und WIndows Server starten kann.
Sofern ich das richtig sehe, besser noch(!), bereits vor dem Export aus Hyper-V in der VM vorbereitend installiert werden und direkt als SCSI-Disk von Proxmox starten kann, nachdem der Transfer der Hyper-V ".vhdx" auf das Proxmox-Storage erfolgt ist?
Falls dem so sei, dann ist es die Lösung auf ein Problem, welches wie ich aus eigener Erfahrung sagen kann, nicht nur im Gesundheitssektor(24/7) für sehr viel Erleichterung, sondern auch bei vielen Systemintegratoren/Sysadmins in KMU-Unternehmen mit aktiver Produktion für viele privat für das berufliche genutzten Stunden sorgt.
@Falk R.
Was ich hieraus für meinen Task mitnehme ist, dass ich bestenfalls bereits im Vorfeld mit deinem Script die VirtIO-Tools auf der zu migrierenden Hyper-V VM installiere, dann die .vhdx rüber transferiere und dort das Diskimage per "qm importdisk" importiere und bestenfalls dann eine direkt startende Windows Server-VM in dem Bruchteil der Zeit lauffähig zu haben?
Da mir noch nicht ganz klar ist, welches Format am sinnvollsten ist, die Frage meinerseits ob qcow2 oder raw, da in vielen Anleitungen noch ein Zwischenschritt genannt wird, mit "qemu-img convert" den es nicht eigentlich nicht mehr Bedarf bzw. als Parameter bei qm importdisk mitgegeben werden kann?
Viele Grüße und noch größeren Dank an dich und die Proxmox Community
#wissenschwamm
Hi, ja das Script ist auch für dich die Lösung für ein nerviges Problem.Hallo in die Runde,
ich wünsche allen ein frohes neues Jahr in der Community
Ich habe vor einiger Zeit bereits mit Proxmox experimentiert und mir darauf aufbauend auch ein Homelab-Cluster und co. eingerichtet und darüber bereits erste Erfahrungen mit Proxmox sammeln können, allerdings spielt bei mir auch der Open-Source Gedanke eine Rolle, weswegen ich es im Zusammenhang mit Windows und co. zuvor nur peripher im beruflichen Kontext zu tun hatte und nun bei einem Unternehmen
angefangen habe welches komplett dabei ist gänzlich weg von Hyper-V auf Proxmox zu migrieren.
Da ich nun zum leidtragenden geworden bin, mitten in der Umstellung und im Unternehmen sehr stark auf KI zur Wissensfindung gesetzt wird, teilweise vermehrt ohne kritische Hinterfragung (mit teils möglichen katastrophalen Auswirkungen) und ich mich hierdurch durch unzählige Beiträge wühlen musste, ist es mittlerweile soweit das ich mein Wochenende nutze.
Langer Rede kurzer Sinn, es gilt mehrere Hyper-V VMs (WinServer 2019&2022) zu migrieren und auch hier kommt das genannte Problem der SCSI-bedingten "INACCESSIBLE_BOOT_DEVICE" Problematik zum tragen.
So wie ich mittlerweile verstanden habe, geht das darauf zurück das Windows selbst bei vorheriger Installation der VirtIO-Tools/Treiber diese während des Boot-Vorganges nicht lädt, weil das Device ja in der Form nie vorhanden gewesen ist.
Die modifizierten Tools von @Falk R. sorgen nun mittels dem anlegen eines SCSI-Dummys dafür, das die VM selbst bei vorherigem Attachement als SATA0 in Proxmox (dann bootet es ja) dafür, dass bei der Umstellung zurück auf VirtIO SCSI SIngle, dass die Treiber auch zum Boot-Prozess vorhanden sind und WIndows Server starten kann.
Sofern ich das richtig sehe, besser noch(!), bereits vor dem Export aus Hyper-V in der VM vorbereitend installiert werden und direkt als SCSI-Disk von Proxmox starten kann, nachdem der Transfer der Hyper-V ".vhdx" auf das Proxmox-Storage erfolgt ist?
Falls dem so sei, dann ist es die Lösung auf ein Problem, welches wie ich aus eigener Erfahrung sagen kann, nicht nur im Gesundheitssektor(24/7) für sehr viel Erleichterung, sondern auch bei vielen Systemintegratoren/Sysadmins in KMU-Unternehmen mit aktiver Produktion für viele privat für das berufliche genutzten Stunden sorgt.
@Falk R.
Was ich hieraus für meinen Task mitnehme ist, dass ich bestenfalls bereits im Vorfeld mit deinem Script die VirtIO-Tools auf der zu migrierenden Hyper-V VM installiere, dann die .vhdx rüber transferiere und dort das Diskimage per "qm importdisk" importiere und bestenfalls dann eine direkt startende Windows Server-VM in dem Bruchteil der Zeit lauffähig zu haben?
Da mir noch nicht ganz klar ist, welches Format am sinnvollsten ist, die Frage meinerseits ob qcow2 oder raw, da in vielen Anleitungen noch ein Zwischenschritt genannt wird, mit "qemu-img convert" den es nicht eigentlich nicht mehr Bedarf bzw. als Parameter bei qm importdisk mitgegeben werden kann?
Viele Grüße und noch größeren Dank an dich und die Proxmox Community
#wissenschwamm
Ich habe immer den Ordner mit den VHDx an den PVE per SMB gemountet und da das importdisk durchgeführt.
Das Zielformat gibt dein Zielspeicher vor.
Wenn du LVM-Thin, ZFS oder Ceph nutzt, immer RAW, falls du NFS oder irgend ein beliebiges Dateisystem nutzt, am besten qcow2.
Tatsächlich ist auch das mit heißer Nadel und ohne viel Erfahrung (mittels ChatGPT) in die Wege geleitet worden, d.h. es gibt aktuell 1x richtigen Proxmox Host (Node1) mit echter Serverhardware und zusätzlich eine Workstation (Node3/Witness) mit durchgereichter GPU für On-Prem KI-Modelle, die ebenfalls Proxmox nutzt und im späteren Setup einerseits als dritte Node3&Witness genutzt werden soll.
Im Moment müssen hierzu erstmal die VMs vom aktuellen HyperV HV migriert werden, damit dieser dann hierauf als zweiter Proxmox Node in Betrieb genommen werden kann, das gesetzte Ziel ist es zusammen mit Ceph zu nutzen, wobei hierzu meine praktische Erfahrung aus meinen Homelab nicht reicht (nur zwei Nodes + RPI als QDevice) um zu bewerten ob in so einer Konstellation Proxmox Ceph überhaupt realisierbar und sinnvoll ist, da sich zumindest die Workstation massgeblich von den anderen beiden Server unterscheidet und mein bisheriger Wissenstand hierzu,der war, dass Proxmox mit Ceph es voraussetzen würde.
Meiner Recherche nach wären das bestenfalls drei völlig identische Knoten (Serverhardware), möglichst (all-)Flashspeicher und min. 10GE-Netzwerk mit getrennten Schnittstellen für Ceph-Kommunikation und Management, wobei das für die stellvertretend genutzte Workstation nicht der Fall ist und Ceph mit zwei Knoten + Witness, wenn ich das noch richtig in Erinnerung habe, nicht möglich oder nicht zielführend ist.
Leider ist das Projekt nicht aus meiner Feder und wie viele andere ITler kennen, mit möglichst minimalem Budget ausgestattet, weswegen auch sowas wie ein kleiner 10GE Switch für die Kommunikation untereinander noch diskutiert werden muss.
Letztlich kann ich zwar darauf hinweisen aber als jemand der noch in der Probezeit ist, ist es natürlich schwierig offen zu sagen, das Teile der Planung auf ChatGPT-Halluzinationen basieren (z.B. Proxmox 9.1.2= Bullseye Paketquellen hinzufügen) und so nicht umsetzbar sind.
Ich schätze dann das folgende Aussage hier aus dem Forum zutreffend ist und sich ein zwei Knoten Ceph-Cluster mit Witness im Zweifelsfall sehr unvorteilhaft für die Datenintegrität und Uptime auswirken kann? ^^
Vielen Dank für deine Rückmeldung, das hilft mir sehr
#wissenschwamm