VMware-to-Proxmox-Migration: Runbook für vSphere-Admins

Wenn dein vSphere-Cluster mit ESXi 7.x, vCenter, NFS- oder VMFS-Datastores und VLAN-Portgruppen 2026 vor Vertragsverlängerung, Support-Ende oder Budgetprüfung steht, brauchst du ein prüfbares Migrations-Runbook. Im internationalen Suchkontext heißt das Thema oft VMware to Proxmox migration; technisch geht es um Boot-Modus, Storage-Layout, Backup-Jobs, Firewall-Regeln, Monitoring, Betriebshandbücher und HA-Verhalten.

Dieser Artikel beschreibt einen Ablauf für vSphere-Admins mit Proxmox VE 9.2. Er behandelt den Proxmox ESXi Import Wizard, Storage- und Netzwerk-Mapping, Windows- und Linux-Remediation, Rollback, Backups, Monitoring und HA-Betrieb. Wenn du die Schritte in einer Laborumgebung nachvollziehen willst, kann die Schulung Migration von VMware zu Proxmox eine passende Ergänzung sein.

Warum VMware-to-Proxmox-Migrationen 2026 auf der Agenda stehen

VMware by Broadcom stellte Ende 2023 und Anfang 2024 den Vertrieb unbefristeter Lizenzen weitgehend auf Subscription-Modelle um. Zusätzlich erreichten vSphere 7.x und vSAN 7.x am 2. Oktober 2025 das Ende des General Support. Infrastruktur-Teams prüfen deshalb Lizenzmodell, Support-Status, Budget, Betriebsrisiko und Zielarchitektur gemeinsam statt getrennt in Einkauf, Betrieb und Security.

Eine Migration ist realistisch, wenn deine Workloads überwiegend aus Standard-x86-VMs bestehen, wenn du Storage- und Netzwerk-Policies technisch nachbilden kannst und wenn Anwendungsowner Wartungsfenster akzeptieren. Ein VMware-Upgrade bleibt plausibler, wenn Betriebsprozesse zwingend vSAN-Stretched-Cluster, NSX-T-Microsegmentation, SRM-Runbooks oder vom Hersteller zertifizierte Appliance-Stacks voraussetzen.

Herstellerangaben zu installierten Proxmox-Hosts oder Community-Größe sind für eine Plattformbewertung nur ein Nebenaspekt. Für deine Entscheidung zählen vor allem Supportvertrag, Paketquelle, Restore-Test, Skill-Aufbau, Monitoring-Integration und eine Abnahme mit den konkreten Anwendungen, RTO-Vorgaben und Compliance-Anforderungen.

Vor der Migration: Inventar, Abhängigkeiten und Risikoanalyse

Beginne mit einem VM-Inventar aus vCenter, PowerCLI und vorhandener CMDB. Erfasse Betriebssystem, vCPU, RAM, virtuelle Disks, Disk-Provisioning, Snapshots, VMware-Tools-Status, Netzwerkkarten, Portgruppen, VLANs, Storage-Policy, Backup-Policy und Kritikalität. Wenn dein Team zuerst vCenter, PowerCLI oder ESXi-Betrieb sauber dokumentieren muss, findest du passende VMware-Schulungen für diese Vorarbeit.

• Ermittle Abhängigkeiten zu Active Directory, DNS-Zonen, DHCP-Scopes, Load-Balancern, Datenbanken, Monitoring-Systemen, Backup-Servern und Firewall-Regeln.
• Dokumentiere Datenfluss-Richtungen konkret, zum Beispiel Web-VM zu SQL Server über TCP 1433 oder Linux-App zu PostgreSQL über TCP 5432.
• Ordne VMs in Pilot, Standard, Komplex und Hochrisiko ein. Hochrisiko umfasst Domain-Controller, Datenbanken, Lizenzserver, Cluster-Nodes und Systeme mit Hersteller-Appliances.

Proxmox ESXi Import Wizard: was automatisiert ist und was nicht

Proxmox VE 8.2 führte im April 2024 einen integrierten Import-Wizard für VMware-ESXi-VMs ein. In aktuellen Proxmox-VE-Versionen richtest du den Import typischerweise über Datacenter → Storage → Add → ESXi ein. Der Zugriff steht über Web-GUI und API bereit. Für das Suchmuster Import ESXi VM into Proxmox ist wichtig: Der Wizard behandelt den ESXi-Host als Storage-Quelle und übersetzt VM-Konfigurationsdetails in das Proxmox-Konfigurationsmodell.

Automatisiert werden typische VM-Parameter wie CPU-Anzahl, RAM, Disk-Zuordnung und Netzwerkkarten-Mapping. Nicht automatisch migriert werden vCenter-Folder, Tags, DRS-Regeln, vSphere-Alarme, Backup-Jobs, Betriebsdokumentation, vDistributed-Switch-Policies und Anwendungsfreigaben. Starte in der Pilotphase maximal einen Import pro ESXi-Host parallel: So bleiben Logs eindeutiger, I/O-Spitzen niedriger und konkurrierende Storage-Operationen leichter nachvollziehbar.

Nach dem Import brauchst du Proxmox-Grundlagen zu KVM, LXC, Storage, Backup und Recovery. Das Proxmox-Grundlagen-Training deckt diese administrativen Themen für den Betrieb nach dem Wechsel ab.

Storage-Mapping: Datastores, Disk-Formate, Performance und Backup

Storage-Mapping entscheidet über Boot-Verhalten, I/O-Latenz und Backup-Fenster. Das Suchmuster Migrate VMDK to Proxmox verkürzt den Vorgang auf die Disk-Datei, tatsächlich bestimmt das Ziel-Storage aber Disk-Format, Thin-Provisioning, Snapshot-Fähigkeit, Replikation und Restore-Zeit.

Lege den Controller-Typ vor dem ersten Produktivstart fest. VirtIO SCSI mit I/O-Thread eignet sich häufig für Linux- und Windows-Server, benötigt bei Windows aber installierte VirtIO-Treiber. Cache-Modus, discard und SSD-Emulation müssen zu Storage und Workload passen. Messe nach dem Import mit fio unter Linux oder diskspd unter Windows, bevor du Datenbank-VMs freigibst.

Plane Backups neu. Proxmox Backup Server arbeitet mit Deduplizierung, Retention-Policies und Restore-Prüfungen. Teste mindestens einen File-Restore und einen vollständigen VM-Restore pro Migrationswelle, bevor du die ursprüngliche VMware-VM löschst.

Netzwerk-Mapping: VLANs, Bridges, Firewall-Regeln und Namen

Übersetze vSwitches und Portgruppen in Linux-Bridge- oder SDN-Konzepte. Ein vSwitch mit VLAN-Portgruppen wird häufig zu einer VLAN-aware Bridge wie vmbr0. Physische Uplinks bündelst du über Linux-Bonds mit LACP, wenn der Switch 802.3ad korrekt konfiguriert ist. Funktionen eines vDistributed Switch musst du als Betriebskonzept neu dokumentieren, zum Beispiel über Proxmox-SDN, Namensstandards und Switch-Konfigurationsvorlagen.

• Nutze technische Bridge-Namen wie vmbr0, vmbr1 und vmbr2 und dokumentiere sprechende Rollen wie Management, VM-LAN, Backup und Storage.
• Dokumentiere jede VLAN-ID mit Zweck, Subnetz, Gateway, DNS-Server, DHCP-Quelle und Monitoring-Probe.
• Prüfe Firewall-Regeln auf geänderte MAC-Adressen, neue Host-IP-Adressen, geänderte Backup-Targets und neue Management-Ports der Proxmox-Nodes.

Passe DNS-A-Records, Reverse-DNS, DHCP-Reservierungen, Routing-Tabellen und Monitoring-Checks vor dem Cutover an. Ein erfolgreicher Ping ersetzt keine Prüfung von TLS-Zertifikaten, Datenbank-Verbindungen und Applikationsports.

Windows-VMs migrieren: Treiber, Boot-Modus, Dienste und Tests

Prüfe vor dem Import BIOS oder UEFI, EFI-Disk, Secure-Boot-Anforderung, Boot-Reihenfolge und Controller-Typ. Installiere VirtIO-Netzwerk- und Storage-Treiber vor dem Cutover oder mounte die VirtIO-ISO im ersten Wartungsfenster. Entferne VMware Tools erst nach erfolgreichem Start und installiere den QEMU Guest Agent, damit Proxmox saubere Shutdowns, IP-Erkennung und Backup-Quiescing unterstützt.

Get-NetAdapter | Format-Table Name, Status, MacAddress
w32tm /query /status
Get-Service | Where-Object Status -eq 'Stopped'

Validiere Domain-Mitgliedschaft, Zeitsynchronisierung, Netzwerkprofil, Windows-Firewall-Profil, Laufwerksbuchstaben, Anwendungsdienste und Windows-Aktivierung. Akzeptanztests umfassen erfolgreichen Login mit Domänenkonto, Zugriff auf zentrale Freigaben, Start aller erwarteten Services, Anwendungstest durch den Owner und fehlerfreie Einträge im Windows-Eventlog für System und Application.

Linux-VMs migrieren: fstab, NIC-Namen, Cloud-Init und Dienste

Linux-VMs scheitern nach dem Import oft an fstab-Einträgen, initramfs, Netzwerkinterface-Namen oder Cloud-Init-Resten. Prüfe GRUB, initramfs-Module für virtio_blk oder virtio_scsi, UUID-basierte Mounts und NetworkManager-, Netplan- oder systemd-networkd-Konfigurationen. Ein VMware-Interface ens192 erscheint unter Proxmox häufig als ens18 oder ens19.

lsblk -f
cat /etc/fstab
ip -br link
systemctl --failed
journalctl -b -p warning

Kontrolliere persistente Routen, nftables oder iptables, firewalld, SELinux- oder AppArmor-Profile und systemd-Units mit After- oder Requires-Abhängigkeiten. Bei Template-VMs entfernst oder änderst du Cloud-Init-Datasources, VMware-Customization-Skripte und alte udev-Regeln, bevor du die VM in ein Proxmox-Template überführst.

Rollback planen: Snapshots, Backups, Wartungsfenster und Abnahme

Definiere vor jeder Welle eine Go/No-Go-Entscheidung mit technischer Checkliste und Business-Abnahme. Die Quell-VM bleibt nach dem Shutdown unverändert, bis der Anwendungsowner die Proxmox-VM freigibt. Jede Schreiboperation auf der neuen VM verhindert einen einfachen Rollback, wenn du die Daten nicht zurücksynchronisierst.

• Lege Wartungsfenster, Freeze-Zeitpunkt, Datenbank-Stop, Snapshot-Zeitpunkt und Import-Start schriftlich fest.
• Erstelle vor dem Cutover ein vollständiges Backup der Quell-VM und nach dem Import ein Proxmox-Backup der Ziel-VM.
• Definiere Akzeptanzkriterien: Boot, Login, Netzwerk, Anwendungstest, Monitoring-Grünstatus, Backup-Erfolg und Owner-Freigabe.

Nach der Migration: Monitoring, Security Hardening und Patching

Integriere Proxmox-Nodes, Cluster-Quorum, Storage, PBS-Backups, ZFS-Pools, SMART-Werte, Ceph-Health und Gast-VMs in dein Monitoring. Zabbix, Checkmk, Prometheus mit pve-exporter oder PRTG prüfen API-Werte, Node-Status, Backup-Jobs und Storage-Füllstände. Ergänze Log-Forwarding zu deinem Syslog- oder SIEM-System.

Härte den Zugriff mit MFA, rollenbasierten Berechtigungen, dedizierten API-Tokens, getrennten Realms, eingeschränktem SSH-Zugriff und Segmentierung des Management-Netzes. Prüfe Update-Repositories, Patch-Rhythmus, Test-Node-Verfahren und Wartungsfenster für Kernel-Updates. Dokumentiere Restore-Prozesse, Incident-Eskalation und Änderungen an Firewall-Objekten.

Für angrenzende Themen wie Linux-Administration, Virtualisierung und Backup-Betrieb findest du weitere Systemadministration-Trainings.

Proxmox VE 9.2 in Produktion: Versionen, HA, SDN und Wartung

Behandle Proxmox VE 9.2 nicht nur als Importziel, sondern als eigene Betriebsplattform. Dokumentiere vor der Freigabe die tatsächlich installierten Paketstände mit pveversion -v und gleiche Debian-Basis, Kernel, QEMU, LXC, ZFS oder Ceph mit den Release Notes und deinen Support-Vorgaben ab. Übernimm keine Versionsnummern aus Präsentationen oder Blogposts ungeprüft in dein Betriebsrunbook.

pveversion -v
ha-manager status
pvesm status

Für HA-Cluster brauchst du klare Regeln für Quorum, Fencing-Ersatzkonzepte, VM-Prioritäten, HA-Gruppen, Wartungsfenster und Kapazitätsreserven. Proxmox HA startet Gäste nach einem Node-Ausfall auf geeigneten Cluster-Nodes neu; es ersetzt keine Anwendungshochverfügbarkeit innerhalb von Datenbanken, Message-Queues oder Active/Active-Applikationen.

Wenn du Proxmox-SDN nutzt, versioniere Zones, VNets, Subnetze, VLAN- oder VXLAN-Mappings, MTU-Werte und Firewall-Regeln wie Code-ähnliche Konfiguration. Für Cluster-Betrieb, Ceph und High Availability passt das Proxmox-Aufbau-Training zu Cluster, Ceph und High Availability.

Konkreter nächster Schritt

Starte mit einer Pilotwelle aus einer Windows-VM und einer Linux-VM ohne Datenbank-Rolle. Dokumentiere das Mapping für CPU, RAM, Disks, VLANs, Firewall-Regeln, Backup-Policy und Monitoring-Checks. Führe den ESXi-Import seriell aus, behebe Treiber- und Boot-Probleme, teste einen Restore aus Proxmox Backup Server und lasse die Anwendung durch den Owner abnehmen. Erst nach dieser Pilotwelle legst du die Reihenfolge für Standard-, komplexe und Hochrisiko-VMs fest.