VMware ESXi zu Proxmox zu migrieren klingt oft nach „Importer anklicken, fertig“. In der Praxis scheitern produktive Umzüge aber nicht an der Installation, sondern an Altlasten in den VMs, an Storage-Verhalten, an falsch geplanten Netzwerkpfaden und an der einfachen Tatsache, dass der Zielhost selbst oft erst noch neu aufgebaut werden muss. Genau für diesen Fall ist dieser Guide gedacht: erst von ESXi auf einen bestehenden Proxmox-Transfer-Host umziehen, dort mit möglichst wenig Downtime weiterlaufen lassen, den Dell-Host sauber auf Proxmox VE neu aufsetzen und die Workloads anschließend auf ihren finalen Host zurückziehen. Proxmox VE bringt dafür inzwischen genau die passenden Bausteine mit: nativen VMware-Import, Storage-Migration und die tiefe Integration von Proxmox Backup Server.
Alle Hostnamen, IPs, VM-Namen und Pfade in diesem Beitrag sind bewusst anonymisiert und als realistische Beispielumgebung aufgebaut. Der Ablauf ist praxisnah, aber leicht verallgemeinert, damit ihr ihn auf eure eigene Infrastruktur übertragen könnt.
Worum es in diesem Guide geht
Unser Beispielszenario sieht so aus:
px-transfer-01.ten.byte 10.40.10.10 bestehender Proxmox-Host als Transfer-Server
esx-prod-01.ten.byte 10.60.10.20 Dell PowerEdge R470 mit VMware ESXi
mgw-esx-01.ten.byte 10.60.10.5 kleiner Linux-Transit-Gateway für den Tunnel
px1.ten.byte 10.40.10.21 derselbe Dell-Server nach Neuinstallation mit Proxmox
bk-legacy-01.ten.byte 10.40.30.40 bisheriger Backup-Server mit Veeam
pbs1.ten.byte 10.40.30.40 derselbe Host später als Proxmox Backup ServerDie Idee hinter diesem Migrationsmuster ist simpel, aber extrem effektiv:
- Ihr nutzt einen bestehenden Proxmox-Host als Transfer- oder Staging-Server.
- Ihr holt die VMs vom ESXi-Host zunächst nicht direkt auf den finalen Dell, sondern auf den Transfer-Host.
- Sobald die VMs dort sauber laufen, könnt ihr den Dell-Server komplett neu aufsetzen.
- Danach zieht ihr die VMs von Proxmox zu Proxmox auf den finalen Zielhost zurück.
- Zum Schluss ersetzt ihr den bisherigen Veeam-Server durch Proxmox Backup Server.
Das ist kein „Quick and Dirty“-Hack, sondern ein sehr sauberer Weg für Umgebungen, in denen ihr die Downtime klein halten wollt und den physischen Zielhost erst noch auf Proxmox drehen müsst.
Ein typischer Ablauf für produktive Gäste könnte so aussehen:
ESXi-VM -> Import auf px-transfer-01 -> Test & Produktivstart auf dem Transfer-Host
-> Dell neu mit Proxmox installieren -> Rückumzug auf px1.ten.byte
-> Backup-Strategie auf PBS umstellenDie Methode ist vor allem dann stark, wenn ihr keinen zweiten identischen Zielhost frei habt, aber trotzdem nicht mit einem Big-Bang-Wochenende arbeiten wollt.
Der Transportpfad zwischen Alt und Neu
In unserem Beispiel liefen die Systeme im selben Rechenzentrum und im selben internen RZ-Netz. Deshalb kann man in so einer Ausnahme ruhig pragmatisch sein. Anstatt sofort einen kompletten Site-to-Site-VPN-Stack aufzubauen, könnt ihr für die Migrationsphase einen GRE-Tunnel verwenden – aber nur dann, wenn das Underlay wirklich privat, kontrolliert und vertrauenswürdig ist. Red Hat dokumentiert ausdrücklich, dass GRE selbst keine Verschlüsselung bietet. StrongSwan beschreibt route-based IPsec/XFRM als Alternative ohne zusätzliche GRE-Kapselung, und WireGuard positioniert sich offiziell als moderner, einfacher VPN-Tunnel mit aktueller Kryptografie. Übersetzt in die Praxis: GRE ist okay für einen isolierten, internen RZ-Transport. Für öffentliche oder fremde Netze würde ich heute zuerst an WireGuard, IKEv2/IPsec oder direkt an eine private L2/L3-Strecke des Providers denken.
Wichtig ist dabei ein technischer Punkt, der in vielen Migrationsskizzen untergeht: ESXi ist nicht automatisch euer GRE-Endpunkt. Wenn ihr auf der VMware-Seite keinen passenden Router oder keine Firewall habt, baut ihr euch dafür einfach einen kleinen Linux-Transit-Host oder eine temporäre Gateway-VM, die im ESXi-Netz hängt. Genau das ist im Alltag oft die sauberste Lösung.
Ein minimalistisches Beispiel für den Tunnel auf dem bestehenden Proxmox-Transfer-Host kann so aussehen:
# px-transfer-01.ten.byte
ip tunnel add gre-mig mode gre local 172.31.250.10 remote 172.31.250.21 ttl 255
ip addr add 10.255.254.1/30 dev gre-mig
ip link set gre-mig mtu 1476 up
ip route add 10.60.10.0/24 via 10.255.254.2 dev gre-migAuf dem Linux-Gateway im VMware-Netz dann spiegelbildlich:
# mgw-esx-01.ten.byte
ip tunnel add gre-mig mode gre local 172.31.250.21 remote 172.31.250.10 ttl 255
ip addr add 10.255.254.2/30 dev gre-mig
ip link set gre-mig mtu 1476 up
sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.10.0/24 via 10.255.254.1 dev gre-migWenn ihr das persistent in Proxmox ablegen wollt, fühlt sich ein Eintrag in /etc/network/interfaces meist am natürlichsten an:
auto gre-mig
iface gre-mig inet static
address 10.255.254.1/30
pre-up ip tunnel add gre-mig mode gre local 172.31.250.10 remote 172.31.250.21 ttl 255
up ip link set gre-mig mtu 1476
up ip route add 10.60.10.0/24 via 10.255.254.2 dev gre-mig
down ip route del 10.60.10.0/24 via 10.255.254.2 dev gre-mig
post-down ip tunnel del gre-migWas ihr danach erwartet, ist kein Hexenwerk. Prüft zuerst den Tunnel selbst:
ip -br addr show gre-mig
ping -c 3 10.255.254.2
tracepath 10.60.10.20Ein plausibles Ergebnis sieht dann etwa so aus:
gre-mig UNKNOWN 10.255.254.1/30
PING 10.255.254.2 (10.255.254.2) 56(84) bytes of data.
64 bytes from 10.255.254.2: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.255.254.2: icmp_seq=2 ttl=64 time=0.401 ms
64 bytes from 10.255.254.2: icmp_seq=3 ttl=64 time=0.398 msDanach messt ihr die nutzbare Bandbreite über genau diesen Pfad, bevor ihr irgendetwas importiert:
iperf3 -c 10.255.254.2 -P 4Wenn hier schon klar ist, dass ihr keine saubere Rate bekommt, braucht ihr auf Storage-Ebene gar nicht erst anfangen. Meine Faustregel ist einfach: erst Tunnel und Bandbreite sauber messen, dann VMs anfassen.
Alternative Wege, die ich im Artikel bewusst mitdenke:
- Wenn ihr nur zwei Linux-Endpunkte verbinden müsst und eine schlanke Lösung wollt: WireGuard.
- Wenn ihr Compliance, Standardisierung und verschlüsselte Site-to-Site-Strecken braucht: route-based IPsec/XFRM.
- Wenn beide Systeme ohnehin im selben Provider-/RZ-Kontext hängen und ihr die Wahl habt: direkte private VLAN- oder Routed-Link-Lösung statt Tunnel.
GRE ist in diesem Guide also kein Dogma, sondern ein bewusstes, pragmatisches Werkzeug für genau diese Ausnahme.
Vorbereitung auf der ESXi-Seite
Der wichtigste Satz in so einer Migration lautet: Nicht die Migration macht die meisten Probleme, sondern die Altlasten in VMware. Genau hier entscheidet sich, ob ihr einen elegant kontrollierten Umzug habt oder nachts auf einen kryptischen VMDK-Fehler starrt. Proxmox-Forum-Fälle zeigen sehr klar, dass Importe oft an vorhandenen Snapshots oder Snapshot-Ketten scheitern; nach dem Entfernen der Snapshots liefen die Importe wieder sauber durch.
Bevor ihr also an Import-Buttons denkt, macht ihr auf VMware-Seite diese Hausaufgaben:
- Änderungsfenster festlegen.
- Backup-Jobs und Automatismen prüfen.
- Snapshots konsolidieren oder löschen.
- Unbenutzte Zusatzplatten identifizieren.
- Letztes Backup ziehen.
- VM sauber herunterfahren.
Gerade der Punkt mit den unbenutzten Platten wird oft übersehen. Viele VMs schleppen über Jahre alte Hilfsdisks, ehemalige Datenplatten oder Snapshot-Reste mit, die im Gast gar nicht mehr verwendet werden. Von außen sieht die VM dann „normal“ aus. Der Importer sieht aber trotzdem jede eingehängte VMDK – inklusive kaputter oder verwaister Descriptor-Dateien.
Auf Linux-Gästen ist lsblk der schnellste erste Blick:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,TYPEEin realistischer Output kann so aussehen:
NAME SIZE FSTYPE MOUNTPOINTS TYPE
sda 120G disk
├─sda1 1G xfs /boot part
└─sda2 119G LVM2_member part
├─rl-root 80G xfs / lvm
└─rl-var 39G xfs /var lvm
sdb 500G ext4 /srv/app disk
sdc 200G diskHier ist sdb offensichtlich produktiv. sdc dagegen ist verdächtig: keine Signatur, kein Mountpoint, kein offensichtlicher Zweck. Das heißt noch nicht automatisch, dass die Platte weg kann. Gerade bei Linux müsst ihr zusätzlich prüfen, ob die Disk vielleicht als LVM-PV, in einem RAID oder in einer Applikationslogik steckt:
blkid
pvs
vgs
lvs
cat /etc/fstab
mount | grep -E '^/dev/'Wenn die Platte weder im Filesystem, noch in LVM, noch in fstab, noch in der Anwendungsdokumentation auftaucht und fachlich niemand mehr einen Zweck bestätigen kann, ist sie ein Kandidat zum Entfernen. Genau diese Platten solltet ihr zuerst im Gast sauber aus dem Betrieb nehmen und danach in VMware aus der VM-Konfiguration entfernen.
Bei Windows macht ihr das Gleiche mit PowerShell oder der Datenträgerverwaltung, zum Beispiel:
Get-Disk | Select Number,FriendlyName,OperationalStatus,PartitionStyle,Size
Get-Volume | Select DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,SizeEin weiterer Klassiker sind Snapshots, die durch alte Backup-Jobs oder abgebrochene Konsolidierungen liegen geblieben sind. Ein typischer, professionell anonymisierter Fehler sieht dann etwa so aus:
failed to stat '/run/pve/import/esxi/esxi-migrate/mnt/dc1/vmware/app-sync-01.ten.byte/app-sync-01.ten.byte_1-000001.vmdk'
TASK ERROR: unable to create VM 109 - cannot import from 'esxi-migrate:dc1/vmware/app-sync-01.ten.byte/app-sync-01.ten.byte_1-000001.vmdk' - could not get size of esxi-migrate:dc1/vmware/app-sync-01.ten.byte/app-sync-01.ten.byte_1-000001.vmdkDer fachlich sauberere Name für dieses Problem ist nicht „Proxmox spinnt“, sondern eher: verwaister Snapshot-Descriptor auf einer nicht mehr verwendeten Zusatzdisk. In der Praxis heißt das fast immer: VMware-Snapshots konsolidieren, alte Backup-Referenzen aufräumen und unnötige Disks aus der VM-Hardware entfernen.
Ein zweiter Punkt, den viele unterschätzen: Plant das Wartungsfenster eher wie für eine Vollkopie als wie für einen smarten Thin-Move. Proxmox weist an mehreren Stellen darauf hin, dass Vollkopien und bestimmte Migrationspfade komplette VM-Image-Daten lesen und kopieren. In realen ESXi-Importen verhalten sich thin-provisionierte VMDKs deshalb oft größer und träger, als man vom tatsächlich belegten Gastdateisystem erwarten würde. Kurz gesagt: Rechnet nicht nur mit „belegte 250 GB“, wenn auf der Platte logisch 5 TB definiert sind.
Mein empfohlenes Ende der Vorbereitungsphase ist immer gleich:
- Backups erfolgreich?
- Snapshots weg?
- Unnötige Disks entfernt?
- Applikation im Wartungsmodus?
- Monitoring informiert?
- VM sauber heruntergefahren?Erst wenn diese fünf Haken sitzen, geht’s auf den Import-Host.
Import auf den Transfer-Host
Der native Import Wizard ist heute einer der größten Pluspunkte von Proxmox VE in Migrationsprojekten. Laut offizieller Proxmox-Dokumentation wurde der Import Wizard in Proxmox VE 8.2 eingeführt, der ESXi-Import wurde mit ESXi-Versionen von 6.5 bis 8.0 getestet, und Gäste auf vSAN lassen sich in der Regel nicht als direkter ESXi-Storage-Import übernehmen. Proxmox empfiehlt außerdem, Importe nicht unkontrolliert zu parallelisieren; als grobe Obergrenze sind maximal vier gleichzeitige VM-Imports sinnvoll.
Der saubere Weg auf dem Transfer-Host sieht dann so aus:
- ESXi als Quelle in Proxmox einbinden.
- Verfügbare Gäste anzeigen lassen.
- Ziel-Storage auswählen.
- Import starten.
- Danach nicht sofort blind booten, sondern Hardware-Konfiguration prüfen.
Für den GUI-Weg reicht die Logik:
Datacenter -> Storage -> Add -> ESXi
Danach ESXi-Quelle auswählen
Virtual Guests anzeigen
VM auswählen
Ziel-Node: px-transfer-01.ten.byte
Ziel-Storage: tank-vm oder zfs-transfer
Import startenProxmox dokumentiert dabei ausdrücklich den Weg über Datacenter → Storage → Add und den Import über die eingebundene Quelle.
Wenn der Direktimport nicht sauber greift – etwa bei Edge Cases, Exporten oder in Situationen, in denen ihr lieber komplett kontrolliert mit Dateien arbeiten wollt – ist OVF/OVA plus qm importovf der bewährte Fallback. Proxmox dokumentiert diesen Weg explizit.
Ein Beispiel:
qm importovf 402 /mnt/pve/esxi-export/app-auth-01/app-auth-01.ovf zfs-transferWas ihr bei einem erfolgreichen Import erwartet, ist sinngemäß so etwas:
importing disk 'scsi0' to 'zfs-transfer:vm-402-disk-0' ...
transferred 128.0 GiB of 128.0 GiB (100.0%)
creating configuration ...
TASK OKDer eigentliche Qualitätsunterschied entsteht aber nach dem Import. Genau dort trennt sich „läuft irgendwie“ von „läuft produktiv sauber“.
Netzwerkseitig müsst ihr den VMware-Portgruppen-Gedanken bewusst auf Proxmox übertragen. Proxmox arbeitet laut Doku mit einem Bridged-Networking-Modell, also Linux-Bridges plus optionalen VLAN-Tags. Deshalb gehört jede importierte VM sofort auf die richtige Bridge, das richtige VLAN und – falls genutzt – in die richtige Firewall-Zone.
Ein typischer Satz an Nacharbeiten könnte so aussehen:
qm set 402 --name app-auth-01.ten.byte
qm set 402 --onboot 1
qm set 402 --memory 8192 --cores 4
qm set 402 --net0 virtio=BC:24:11:8D:02:01,bridge=vmbr20,tag=20,firewall=1
qm set 402 --scsihw virtio-scsi-single
qm set 402 --machine q35
qm set 402 --bios ovmfBei Linux-Gästen ist der Wechsel auf VirtIO meistens unkompliziert. Bei Windows-Gästen müsst ihr sauberer denken. Proxmox dokumentiert die VirtIO-Treiber separat; die Windows-Best-Practice-Seiten empfehlen für neue Windows-VMs SCSI mit VirtIO SCSI single, und der Gast braucht die passenden VirtIO-Treiber für Storage und Netzwerk. Wenn ihr für den allerersten Boot maximale Kompatibilität wollt, startet im Zweifel zunächst konservativer und schwenkt danach auf VirtIO um.
Was ich direkt nach dem Import immer prüfe:
- Stimmt der Boot-Modus?
UEFI bleibt UEFI. Legacy bleibt Legacy. - Hängt jede NIC auf der richtigen Bridge?
- Ist die VM-Firewall in Proxmox konsistent mit dem Zielnetz?
- Ist der SCSI-/Disk-Bus sinnvoll?
- Ist die CPU-Konfiguration bewusst gewählt?
- Sind unbenutzte alte Disk-Referenzen wirklich weg?
Gerade die Firewall ist im Staging-Szenario wichtig. Sobald die VM auf dem Transfer-Host wieder anläuft, wollt ihr möglichst wenig Downtime – aber nicht durch versehentlich zu offene Regeln erkaufen. In der Praxis heißt das oft: erst auf dem Transfer-Host die minimal nötigen Freigaben aktivieren, Dienste hochfahren, Funktion prüfen, dann den Dell neu installieren.
Wenn das klappt, habt ihr das Schwierigste bereits geschafft: Die Workloads sind nicht mehr an VMware und nicht mehr an dem alten Dell-Setup festgenagelt.
Den Dell sauber auf Proxmox neu aufsetzen
Sobald die VMs stabil auf dem Transfer-Host laufen, könnt ihr den Dell PowerEdge kontrolliert platt machen und sauber mit Proxmox VE neu aufbauen. Genau das ist der große Vorteil dieses Migrationsmusters: Ihr müsst den finalen Zielhost nicht unter Zeitdruck während des eigentlichen VMware-Cutovers konfigurieren.
Für den physischen Aufbau über iDRAC ist der Ablauf klassisch:
- ISO mounten.
- Vom virtuellen Medium booten.
- Altes ESXi-Layout vollständig entfernen.
- Proxmox sauber installieren.
- Storage, Netzwerk, Repos, Hostname, Zeitzone und Monitoring vorbereiten.
Wenn ihr ZFS einsetzen wollt, ist das genau der richtige Zeitpunkt, es sauber zu tun. Der Proxmox-Installer unterstützt ZFS direkt als Root-Dateisystem samt Auswahl des RAID-Typs. OpenZFS empfiehlt in Enterprise-Umgebungen ECC ausdrücklich, ausreichend RAM ist wichtig, Whole-Disk-Setups sind die bevorzugte Betriebsart, und die OpenZFS-Hardware-Doku weist darauf hin, dass Hardware-RAID ZFS-Selbstheilung und Sichtbarkeit auf Blockebene einschränken kann. Für einen VM-Host mit mehreren HDDs ist RAIDZ2 das naheliegende ZFS-Pendant zu dem, was viele informell als „RAID6“ bezeichnen. Wenn ihr dagegen maximale IOPS braucht, sind Mirrors oft die bessere Wahl.
Kurz gesagt: Wenn ZFS drauf soll, dann möglichst so:
- Controller im HBA-/IT-Modus oder Disks einzeln durchreichen.
- Keine unnötige RAID-Abstraktion unter ZFS.
- ECC, wenn die Plattform es hergibt.
- Genug RAM einplanen.
- Whole disks statt „irgendwelcher Legacy-Partitionen“.
Ein Beispiel für einen zusätzlichen Datenpool für VM-Disks könnte so aussehen:
zpool create -o ashift=12 tank raidz2 \
/dev/disk/by-id/wwn-0x5000cca301111111 \
/dev/disk/by-id/wwn-0x5000cca301222222 \
/dev/disk/by-id/wwn-0x5000cca301333333 \
/dev/disk/by-id/wwn-0x5000cca301444444
zfs set compression=zstd tank
zfs create tank/vmdataWenn ihr viele HDDs und metadatenlastige Workloads habt – besonders später für PBS – kann ein SSD-basiertes Special Device sinnvoll sein. Proxmox dokumentiert diese Option explizit, warnt aber auch klar: Das Special Device ist kritisch, seine Redundanz muss zum Pool passen, und das Ganze ist nichts, was man mal eben „zurückdreht“.
Auch das Netzwerk sollte jetzt nicht nebenbei, sondern bewusst aufgebaut werden. Ein realistisches Beispiel in /etc/network/interfaces:
auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno2 inet manual
auto bond0
iface bond0 inet manual
bond-slaves eno1 eno2
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer3+4
auto vmbr0
iface vmbr0 inet static
address 10.40.10.21/24
gateway 10.40.10.1
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
auto vmbr30
iface vmbr30 inet static
address 10.40.30.21/24
bridge-ports none
bridge-stp off
bridge-fd 0Was ich auf dem finalen Host außerdem immer direkt festlege, ist die CPU-Strategie für die künftigen VMs. Proxmox weist mehrfach darauf hin, dass host auf ungleichen CPU-Generationen oder gar zwischen Intel und AMD Live-Migrationen brechen kann. Wenn ihr später zwischen mehreren Proxmox-Knoten sauber migrieren wollt, definiert lieber bewusst ein ausreichend kompatibles CPU-Modell, statt überall blind host zu nutzen.
Genau deshalb macht ein Beispiel wie dieses oft mehr Sinn als host:
qm set 402 --cpu x86-64-v2-AESNicht, weil host pauschal falsch wäre, sondern weil sauber planbare Migration meist wichtiger ist als die letzten paar Prozent Spezialoptimierung einer einzelnen VM.
Rückumzug von Proxmox zu Proxmox
Wenn der Dell frisch mit Proxmox läuft, die Bridges stehen, der Storage sauber ist und ihr einmal trocken getestet habt, beginnt die zweite Phase: Rückumzug vom Transfer-Host auf den finalen Proxmox-Host.
Dafür gibt es drei saubere Wege:
- Cluster-Migration, wenn beide Hosts in einem echten Cluster hängen.
- Backup und Restore, wenn ihr einen planbaren Offline-Cutover wollt.
- Remote-Migration, wenn ihr getrennte Proxmox-Umgebungen verbindet.
Proxmox dokumentiert qm remote-migrate, weist aber ausdrücklich darauf hin, dass diese Funktion experimentell ist. Für einen kontrollierten Produktivwechsel bevorzuge ich deshalb in vielen Fällen weiterhin Backup/Restore oder eine klassische Cluster-Migration. Zusätzlich dokumentiert Proxmox Storage-Migration als Weg, Disk-Images zwischen Storages oder Formaten zu bewegen. Nach Storage-Moves empfiehlt Proxmox außerdem, im Gast fstrim laufen zu lassen, damit Thin-/Sparse-Backends den Platz sauber zurückbekommen.
Für einen robusten Offline-Cutover ist Backup/Restore oft unspektakulär – und genau deshalb gut. Ein beispielhafter Ablauf auf dem Transfer-Host:
vzdump 402 --mode stop --storage backup-nfs --compress zstdErgebnis zum Beispiel:
INFO: starting new backup job: vzdump 402 --mode stop --storage backup-nfs --compress zstd
INFO: VM Name: app-auth-01.ten.byte
INFO: including disk 'scsi0' 'zfs-transfer:vm-402-disk-0' 120G
INFO: creating vzdump archive '/mnt/pve/backup-nfs/dump/vzdump-qemu-402-2026_04_29-22_15_02.vma.zst'
INFO: Finished Backup of VM 402 (00:07:18)
INFO: Backup finished successfullyAuf dem finalen Host dann:
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-402-2026_04_29-22_15_02.vma.zst 402 --storage tankWenn ihr stattdessen einen exportierten OVF- oder Disk-Weg verwendet, könnt ihr analog mit qm importovf oder Storage-Moves arbeiten. Wichtig ist nicht die Religion der Methode, sondern dass ihr den Weg wiederholbar und testbar haltet.
Nach dem Restore oder Move kommt der Teil, der über ruhige Nächte entscheidet: die Abnahme.
Meine Mindest-Checkliste sieht so aus:
- VM bootet ohne manuelle Eingriffe.
- Richtige IP, richtige Default-Route, richtige VLAN-Zuordnung.
- Applikationsdienst startet sauber.
- Datenpfade, Mounts, Datenbanken, Queues und Sockets stimmen.
- DNS, SMTP, LDAP, API-Ziele und externe Abhängigkeiten sind erreichbar.
- Monitoring und Logging melden die VM wieder korrekt an.
- Backup-Job ist neu zugeordnet.
onboot, Start-Reihenfolgen und Firewall-Regeln stimmen.
Unter Linux-Gästen gehört nach einem Storage-Umzug oft auch ein bewusstes fstrim dazu:
fstrim -avEin realistischer Output:
/: 14.2 GiB trimmed
/var: 3.1 GiB trimmedGerade wenn ihr auf ZFS mit sparse/thin arbeitet, kann das später helfen, die Belegung wieder sauber zu normalisieren.
Wenn nach dem Rückumzug alles funktioniert, bleibt nur noch das saubere Aufräumen:
- alte Transfer-VM stoppen,
- Snapshots/Backups prüfen,
- DNS/Monitoring final umhängen,
- Altlasten auf dem Transfer-Host entfernen,
- Kapazitäten und Dokumentation aktualisieren.
Das Ziel ist nicht nur „läuft“, sondern „läuft und ist administrativ wieder ordentlich“.
Den alten Veeam-Server zum Proxmox Backup Server umbauen
Wenn die produktiven VMs auf dem finalen Proxmox-Host stabil laufen, ist der bisherige Veeam-Server ein idealer Kandidat für den nächsten Schritt: Proxmox Backup Server. PBS lässt sich laut offizieller Doku entweder per ISO direkt auf Bare Metal installieren oder als Paket auf einem Debian-Host ergänzen. Die Plattform bringt inkrementelle Backups, Deduplizierung, Kompression und clientseitige Verschlüsselung mit. Für den Alltag sind vor allem Datastores, Prune, Garbage Collection, Verify Jobs und optional Sync Jobs auf ein zweites PBS relevant.
Wenn ihr den ehemaligen Backup-Server sauber repurposet, würde ich das so denken:
- Erst warten, bis alte Aufbewahrungsfristen und eventuelle Restore-Pflichten aus der Veeam-Welt geklärt sind.
- Dann Host sauber neu aufsetzen.
- Danach PBS als eigenständige Appliance installieren.
- Datastore auf ZFS anlegen.
- PBS in Proxmox VE als Backup-Storage einbinden.
- Prune, Verify und GC direkt mit aufsetzen.
- Optional: später zweites PBS oder Offsite-Sync ergänzen.
Falls ihr PBS auf Debian installieren wollt, ist das grundsätzlich möglich; die offizielle Dokumentation weist aber zu Recht darauf hin, dass das darunterliegende Debian und das Storage-Layout dann bereits sauber vorbereitet sein müssen. Für dedizierte Produktionsboxen ist das ISO oft der angenehmere Weg.
Ein einfacher CLI-Start auf dem PBS könnte so aussehen:
proxmox-backup-manager datastore create vm-backups /backup/vm-backups
proxmox-backup-manager datastore update vm-backups \
--prune-schedule 'daily' \
--keep-last 7 \
--keep-daily 14 \
--keep-weekly 8 \
--keep-monthly 12 \
--gc-schedule 'daily' \
--verify-new 1Diese Syntax und die zugrunde liegenden Optionen sind in der PBS-Dokumentation beschrieben; genauso könnt ihr Datastores und Schedules natürlich in der GUI anlegen.
Wenn ihr später eine zweite PBS-Instanz aufbaut, wird Sync interessant. PBS kann Datastore-Inhalte von einer Remote-Instanz pullen und über Sync Jobs regelmäßig abgleichen. Genau das ist ein sehr eleganter Weg, um aus „ein Backupserver im Rack“ ein belastbareres Backup-Konzept zu machen.
Für die tägliche Praxis empfehle ich euch ein Setup in dieser Denke:
- Kritische Produktions-VMs: tägliche Backups.
- Kürzere RPOs bei Bedarf zusätzlich über häufigere Jobs.
- Prune-Regeln direkt beim Aufsetzen setzen.
- Verify aktivieren.
- GC nicht vergessen.
- Wer zwei Standorte oder zwei Boxen hat: Sync einplanen.
PBS ist damit nicht nur „der Nachfolger von Veeam in dieser Umgebung“, sondern ein echter Architekturbaustein eurer neuen Proxmox-Plattform.
Fazit
Wenn ihr so eine Migration sauber aufzieht, wird aus „Wir müssen VMware irgendwie loswerden“ kein chaotisches Wochenendprojekt, sondern ein strukturierter Plattformwechsel.
Der eigentliche Schlüssel liegt nicht in einem einzigen Wunder-Tool, sondern in der Reihenfolge:
- erst einen sicheren Transportpfad aufbauen,
- dann VMware-Seite bereinigen,
- dann auf einen Transfer-Host importieren,
- dann den finalen Dell richtig neu aufsetzen,
- dann kontrolliert auf den Zielhost zurückziehen,
- danach die Backup-Welt auf PBS modernisieren.
Das ist der Punkt, an dem der Umstieg plötzlich sehr logisch wirkt. Ihr reduziert Risiko, verteilt die Arbeit in klare Phasen und vermeidet den größten Fehler in solchen Projekten: alles gleichzeitig machen zu wollen.
Wenn ich das Ganze in einem Satz zusammenfassen müsste, wäre es dieser: Nicht direkt vom alten ESXi auf den finalen Zielhost springen, wenn der Zielhost selbst noch Baustelle ist – nutzt einen Transfer-Host, entschärft die Migration in zwei saubere Schritte und baut den finalen Proxmox-Host so auf, als würdet ihr ihn die nächsten Jahre betreiben wollen.
Genau dann wird aus einem reinen Hypervisor-Wechsel eine echte Infrastruktur-Verbesserung.
⚠️ Hinweis: Wir bemühen uns um größtmögliche Genauigkeit, können aber keine Fehlerfreiheit garantieren. Die Nutzung erfolgt auf eigene Gefahr.