Alles zur Checkliste gebündelt – VMware→PVE und Hyper-V→PVE
Checkliste VMware → Proxmox
Proxmox VE bringt seit Version 8.2 einen eigenen Import-Assistenten mit, der sich direkt mit einem ESXi-Host oder vCenter verbindet und VMs samt Konfiguration übernimmt – ohne Umweg über manuellen OVF-Export/Import.
VMware Tools vor der Migration sauber deinstallieren (über Programme/Features oder vmware-toolbox-cmd) – sonst können alte Treiber nach dem Wechsel Konflikte verursachen
VirtIO-Treiber vorbereiten: das virtio-win-Treiber-ISO einhängen und insbesondere den Storage-Treiber viostor vor dem ersten Boot unter Proxmox installieren – sonst startet Windows mit Bluescreen 0x7B (kein Bootdatenträger gefunden)
Übernahme entweder per Import-Assistent direkt vom ESXi/vCenter (ab PVE 8.2) oder klassisch per OVF-Export mit ovftool und anschließendem qm importovf
Alternativ Festplatten einzeln konvertieren: qemu-img convert -f vmdk quelle.vmdk -O qcow2 ziel.qcow2, danach per qm importdisk der Ziel-VM zuordnen
Boot-Modus prüfen: BIOS-VMs bleiben bei SeaBIOS, EFI-VMs benötigen in Proxmox den OVMF-Bios-Typ mit passender EFI-Disk – eine Fehlkonfiguration hier verhindert den Boot komplett
Netzwerk: vSwitch-Portgruppen auf Linux-Bridges (vmbr0 etc.) abbilden und IP-Konfiguration prüfen – bei DHCP kann sich durch die neue virtuelle MAC-Adresse die zugewiesene IP ändern
Mit Windows-Neuaktivierung rechnen: der Wechsel der virtuellen Hardware ändert den Hardware-Fingerprint, KMS- oder MAK-Aktivierung meldet sich unter Umständen neu
🎧 Block 1: Die zwei Checklisten
Checkliste Hyper-V → Proxmox
Hyper-V-Integrationsdienste in der VM deinstallieren (Systemsteuerung → Programme oder VM-Einstellungen), danach VirtIO-Treiber-ISO einhängen und installieren
Wichtiger Stolperstein vorab: vorhandene Hyper-V-Checkpoints (frühere „Snapshots") in Hyper-V-Manager zusammenführen bzw. löschen, bevor exportiert wird – sonst bricht die Snapshot-Kette beim Export ab
Festplatten konvertieren: qemu-img convert -f vhdx quelle.vhdx -O qcow2 ziel.qcow2 wandelt direkt, ohne Umweg über das ältere VHD-Format – vorher mit qemu-img info quelle.vhdx prüfen, ob eine dynamische oder fixe Disk vorliegt
Generation-1-VMs sind BIOS/MBR-basiert und lassen sich meist direkt mit SeaBIOS starten; Generation-2-VMs sind UEFI mit GPT-Partitionstabelle und benötigen in Proxmox den OVMF-Bios-Typ
Für Windows 11 unter Generation 2 zusätzlich ein virtuelles TPM einrichten: qm set VMID --tpmstate0 storage:1,version=v2.0, da Windows 11 zwingend TPM 2.0 voraussetzt
Nach dem Boot Netzwerkadapter neu einrichten (Hyper-V nutzt eigene Adaptertypen) und Windows-Aktivierung wie bei VMware-Migrationen prüfen
Downtime-Fenster & Rollback
Migrationsfenster realistisch kalkulieren statt Wunschdenken kommunizieren – lieber ein großzügiges Fenster ankündigen und früher fertig sein als umgekehrt.
Faustregel für die Datenübertragung: bei 1-GbE-Anbindung realistisch ca. 100 MB/s, ein 1-TB-Disk-Image braucht damit grob 3 Stunden reine Kopierzeit – Grundlage für die Fenster-Kalkulation
„Seed & Sync"-Ansatz für große VMs: den Großteil der Daten Tage vorher in Ruhe kopieren, im eigentlichen Wartungsfenster nur noch das Delta seit dem letzten Sync übertragen und dann umschalten – verkürzt die eigentliche Downtime auf einen Bruchteil
Goldene Regel: die alte Umgebung erst abschalten, wenn die neue nachweislich läuft – nie beide Brücken gleichzeitig abbrechen
Rollback-Fenster einplanen: Quelle (VMware-/Hyper-V-VM) mindestens 1–2 Wochen ausgeschaltet, aber nicht gelöscht bereithalten, bevor sie endgültig abgebaut wird
Sofort nach der Migration einen Proxmox-Snapshot der neuen VM anlegen – geht in den ersten Tagen etwas schief, kann auch Proxmox-seitig zurückgerollt werden, ohne auf die alte Quelle zurückgreifen zu müssen
DNS-TTL vor dem Umschalten absenken und IP-Adressen nach Möglichkeit beibehalten, um Folgeänderungen an Firewalls und externen Verweisen zu vermeiden
🎧 Block 2: Downtime, Rollback & Sizing
Kapazitätsplanung / Sizing
Reale Auslastung statt zugewiesener Ressourcen erfassen: CPU-, RAM- und Storage-Nutzung über 2–4 Wochen aus vCenter- bzw. Hyper-V-Performance-Daten auswerten, nicht nur die konfigurierte Größe übernehmen
Realistische Überbuchung einplanen: vCPUs typischerweise im Verhältnis 2:1 bis 4:1 zu physischen Kernen möglich, RAM dagegen eher konservativ dimensionieren (Ballooning existiert, ist bei performancekritischen Workloads aber riskant)
Reserve für Wachstum und für den HA-Ausfallfall einplanen: fällt in einem 4-Node-Cluster ein Node aus, müssen die verbleibenden drei dessen VMs mittragen können
Faustregel: Cluster im Normalbetrieb nicht über ca. 70–80 % Auslastung pro Node fahren, sonst fehlt nach einem Node-Ausfall der Platz, damit betroffene VMs per HA neu starten
Storage-Thin-Provisioning nur mit Monitoring einsetzen – tatsächliche Belegung regelmäßig prüfen, damit der Pool nicht unbemerkt volläuft
Nicht auf Kante planen: Reserve ist keine Verschwendung, sondern die Versicherung gegen den Ausfalltag
Automatisierung
Proxmox bietet eine vollständige REST-API (Port 8006) mit API-Token-Authentifizierung als Ersatz für PowerCLI-Skripte – jede Aktion der Web-UI lässt sich auch per API auslösen
Ansible für Konfiguration und Rollout, meist über Community-Collections mit Proxmox-Modulen; Terraform (z. B. Provider bpg/proxmox) für das deklarative Aufsetzen ganzer Umgebungen
Wiederholbare Deployments statt Klickarbeit: einmal beschrieben, beliebig oft identisch ausgerollt
Für den Dienstleister mit vielen Kunden besonders lohnend: eine saubere Vorlage einmal bauen und pro Kunde nur die Parameter (IPs, Ressourcengrößen, Hostnamen) austauschen
Infrastructure-as-Code-Definitionen versioniert in Git ablegen – nachvollziehbare Änderungshistorie, einfacheres Onboarding neuer Kollegen und Basis für Compliance-Nachweise
Für einzelne Kunden mit wenigen VMs lohnt sich der Aufwand oft nicht, für wiederkehrende Standard-Rollouts über viele Kunden hinweg dagegen deutlich
🎧 Block 3: Automatisierung & Templates
Templates & Cloud-Init
Template-Erstellung: VM einmal sauber aufsetzen, benötigte Pakete/Agenten (u. a. qemu-guest-agent) installieren, dann mit qm template VMID in ein Template umwandeln
Bei Windows-Vorlagen vorher Sysprep ausführen, damit jeder Klon eine eigene SID erhält – ohne Sysprep teilen sich alle Klone dieselbe SID, was vor allem in Active-Directory-Umgebungen zu Problemen führt
Bei Linux-Vorlagen Maschinen-ID und SSH-Host-Keys vor der Template-Umwandlung entfernen (z. B. truncate -s0 /etc/machine-id), damit jeder Klon beim ersten Boot frische Werte generiert
Linked Clones (qm clone TMPLID NEWID --full 0) teilen sich die Basis-Disk des Templates und sparen dadurch Speicher und Klonzeit gegenüber Full Clones
Cloud-Init über eine eigene virtuelle Disk am Template: konfiguriert Hostname, Netzwerk, Benutzer und SSH-Keys beim ersten Start automatisch, ganz ohne Login – funktioniert am besten mit vorbereiteten Cloud-Images (z. B. offizielle Debian/Ubuntu-Cloud-Images)
Ergebnis: standardisierte, sofort einsatzbereite VMs in Sekunden bis Minuten statt manueller Ersteinrichtung pro Kunde
Mandantenfähigkeit (MSP)
Ressourcen-Pools gruppieren die VMs, Storage und weitere Objekte eines Kunden zu einer Einheit innerhalb desselben Clusters
Rechte und ACLs pro Pool vergeben, z. B. über Rollen wie PVEVMAdmin oder PVEAuditor – Kunde A sieht und verwaltet nur seine eigenen Maschinen
Anbindung an AD/LDAP oder eine separate Proxmox-Realm pro Kunde ermöglicht granulare, delegierte Administration ohne gemeinsame Zugangsdaten
Wichtige Einschränkung: Proxmox erzwingt über Pools keine harten Ressourcen-Kontingente wie z. B. VMware vCloud Director – Kapazitätsplanung und Monitoring müssen das im Blick behalten
Pools trennen nur die Verwaltung, nicht das Netzwerk: für echte Mandantentrennung zusätzlich VLANs (802.1Q) oder Proxmox SDN mit eigenen Zonen/VNets pro Kunde einsetzen
Erst Pools plus Rechte und VLANs/SDN zusammen ergeben echte Mandantentrennung – eines allein ist nur die halbe Miete
🎧 Block 4: Mandantenfähigkeit & Lessons Learned
Lessons Learned
Vorbereitung schlägt Improvisation – immer: eine dokumentierte Migration (Netzplan, IP-Liste, Zugangsdaten, Lizenzschlüssel) läuft entspannter und schneller ab als eine spontane
Immer testen: Netzwerkerreichbarkeit, Windows-/Software-Aktivierung, Anwendungsfunktion – und vor allem den ersten Restore aus dem neuen PBS-Backup, bevor die Migration als abgeschlossen gilt
Erst ins Testlabor, dann auf den Kundenserver – ein Testcluster (notfalls auch nested auf einer einzelnen kräftigen Maschine oder auf ausgemusterter Hardware) deckt Überraschungen auf, bevor sie beim Kunden passieren
Komplexe Fälle wie Domain-Controller oder Datenbank-Cluster vorher im Testlabor Schritt für Schritt durchspielen – das macht die Zeitschätzung fürs echte Wartungsfenster belastbar statt geraten
Panik ist ein schlechter Architekt, aber ein Testlabor ist ein guter Lehrer – wer Proxmox in Ruhe geübt hat, migriert gelassen.
