Nutanix-Ablösung planen: WZ-IT unterstützt Vergleich, AHV-Inventur und Migration zu Proxmox. Erstgespräch vereinbaren.
Der folgende Ablauf verbindet dokumentierten OVA-Export mit OVF- oder Disk-Import. Er enthält Befehle für Import, Disk-Zuordnung und Nacharbeiten. Die konkrete Kombination aus Prism-, AOS-, Gast- und PVE-Version muss vor dem Produktivwechsel geprüft werden. Stand: Oktober 2026.
Inhaltsverzeichnis
- 1. Abhängigkeiten und Rückfallweg erfassen
- 2. VM über Prism Central exportieren
- 3. OVF oder Disks nach Proxmox importieren
- 4. Gast und Netzwerk isoliert prüfen
- 5. Cutover und Betrieb vereinbaren
- Quellen
1. Abhängigkeiten und Rückfallweg erfassen
Inventarisieren Sie VMs, Disks, Bootmodus, Netzwerkzuordnungen, Gasttreiber und Anwendungsabhängigkeiten. Nutanix Files, Objects und Volumes sind eigene Datenservices und werden nicht durch den Import einer VM automatisch ersetzt. Erfassen Sie deren Zielsysteme getrennt. Prüfen Sie Anwendungsfreigaben, Backup und Wiederherstellung sowie zulässige Unterbrechungen.
Ein Plattformvergleich steht unter Nutanix-Alternative Proxmox.
2. VM über Prism Central exportieren
Prism Central dokumentiert Export as OVA mit QCOW2 oder VMDK als Diskformat. Prüfen Sie zuerst, ob der Ablauf für Ihre Version und VM unterstützt ist. Erstellen Sie einen konsistenten Datenstand entsprechend der Anwendung und exportieren Sie zunächst eine abgegrenzte Test-VM. Laden Sie das resultierende Archiv herunter und kontrollieren Sie Vollständigkeit und sicheren Transfer. Für den finalen Export dieser Anleitung empfehlen wir nach dem abgestimmten Schreibstopp ein kontrolliertes Herunterfahren des Gasts. Der Testexport legt fest, welche Exportoptionen Ihre Prism-Version tatsächlich bereitstellt. Grundlage: Nutanix Prism Central Infrastructure Guide.
3. OVF oder Disks nach Proxmox importieren
Entpacken Sie das OVA-Archiv in einem geeigneten Arbeitsverzeichnis. Prüfen Sie OVF-Beschreibung und Diskdateien. Proxmox dokumentiert den Import über qm importovf und den separaten Disk-Import. Die konkrete VM-ID, Storage-ID und Dateipfade werden aus Ihrer Umgebung übernommen; hier werden keine produktiven IDs vorgegeben. Details: Proxmox VM-Import.
Der dokumentierte OVF-Aufruf hat folgende Form. NEW_VMID, Pfad und Storage sind Platzhalter, vor der Ausführung durch eine freie ID und geprüfte Zielwerte zu ersetzen:
qm importovf NEW_VMID /path/to/vm.ovf TARGET_STORAGE
Der OVF-Import erstellt eine neue VM und importiert ihre Disks. Das Netzwerk wird manuell zugeordnet. Falls nur ein separates Disk-Image vorliegt, legen Sie eine passende leere Ziel-VM an, importieren die Disk über den dokumentierten Disk-Import und verbinden sie anschließend mit dem vorgesehenen Controller und der Bootreihenfolge. Ein erfolgreich importiertes, aber nicht zugeordnetes Laufwerk ist noch keine bootfähige VM. Prüfen Sie den Ziel-Storage und genügend freie Kapazität, bevor der Import startet. Grundlage: offizielles Proxmox-Quelldokument zum VM-Import.
Behalten Sie den Export und das Quellsystem bis zur Abnahme. Der Import einer Datei ist keine automatische Übernahme aller Prism-Einstellungen.
Disk-Import und Nacharbeiten. Liegt statt eines OVF nur ein Disk-Image vor, legen Sie die Ziel-VM an, importieren die Disk und hängen sie als Bootlaufwerk ein. Das Beispiel zeigt einen UEFI-Linux-Gast (IDs, Namen, Bridge und VLAN sind Platzhalter):
qm create 150 --name app01 --memory 8192 --cores 4 --ostype l26 \
--bios ovmf --machine q35 --net0 virtio,bridge=vmbr0,tag=20
qm disk import 150 /tmp/export/disk0.qcow2 local-zfs
qm set 150 --scsihw virtio-scsi-single --scsi0 local-zfs:vm-150-disk-0 --boot order=scsi0
qm set 150 --efidisk0 local-zfs:1,efitype=4m,pre-enrolled-keys=1 # nur bei UEFI-Gästen
qm set 150 --agent enabled=1
Bei BIOS-Gästen entfallen --bios ovmf --machine q35 und die EFI-Disk. Die importierte Disk erscheint zunächst als „unused“ und wird erst durch qm set mit dem Controller verbunden. Ein bereits importiertes OVF-Ergebnis prüfen Sie mit qm config 150.
| Gast | Nacharbeit nach dem Import |
|---|---|
| Linux | Die benötigten VirtIO-Treiber bringt der Kernel meist mit; Controller und Netzwerkkarte auf VirtIO umstellen, Guest Agent (qemu-guest-agent) installieren |
| Windows | VirtIO-Treiber vor dem Wechsel von SATA oder IDE auf VirtIO installieren, sonst bootet der Gast nicht; Guest Agent und Treiber-ISO aus dem Proxmox-Umfeld verwenden |
| Beide | Nutanix-Gasttools (NGT) entfernen, wenn sie installiert waren, und Netzwerkschnittstellen in der Gastkonfiguration auf die neuen Namen anpassen |
4. Gast und Netzwerk isoliert prüfen
Vergleichen Sie CPU, RAM, BIOS/UEFI, Bootreihenfolge, Diskcontroller und Netzwerkkarten mit der Inventur. Ordnen Sie Bridges und VLANs bewusst zu. Prüfen Sie VirtIO-Treiber und Guest Agent für das jeweilige Betriebssystem. Starten Sie den importierten Gast zunächst isoliert, damit identische IP-Adressen oder parallel aktive Anwendungsinstanzen keinen Konflikt erzeugen.
Dokumentieren Sie Boot, Datenträger, Netz, Dienste und Anwendungstests. Die KVM-Basis von AHV und die QEMU/KVM-VMs von Proxmox ersetzen diese Abnahme nicht. Ein erfolgreicher Boot ist noch kein Nachweis vollständiger Datenkonsistenz.
| Prüfbereich | Festzuhaltender Nachweis |
|---|---|
| Boot und Disks | Firmware, Bootdisk, erkannte Volumes und Treiber |
| Netzwerk | MAC-/IP-Zuordnung, VLAN, DNS und Erreichbarkeit der Abhängigkeiten |
| Anwendung | Fachliche Funktionsprüfung und konsistenter Datenstand |
| Rückfall | Abbruchkriterium, verantwortliche Person und Umgang mit neuen Zieldaten |
Diese Liste ist ein Abnahmevorschlag. Windows- und Linux-Gäste benötigen ihre jeweilige Treiber- und Betriebssystemprüfung; die Proxmox-VM-Dokumentation behandelt Controller, Firmware und Guest Agent.
5. Cutover und Betrieb vereinbaren
Legen Sie Schreibstopp, letzten konsistenten Export, Umschaltung, fachliche Abnahme und Rückfallkriterien fest. Quell- und Zielsystem dürfen nicht unkoordiniert gleichzeitig produktiv schreiben. Datenvolumen und Anwendung bestimmen den Ablauf; es gibt hier keine pauschale Dauer oder Ausfallzeitzusage.
Planen Sie anschließend Backups und einen Restore-Test. Managed Proxmox deckt den vereinbarten Zielbetrieb ab; Umfang und Zuständigkeiten werden für das Zielsystem festgelegt.
Migration und Zielbetrieb abstimmen: Nutanix-Ablösung mit WZ-IT verbindet AHV-Inventur und Migrationsplanung. Für den anschließenden vereinbarten Betrieb steht Managed Proxmox.
