Plan a Nutanix exit: WZ-IT supports comparison, AHV inventory and migration to Proxmox. Book an initial consultation.
This workflow combines documented OVA export with OVF or disk import. It includes commands for import, disk assignment and rework. Validate the specific combination of Prism, AOS, guest and PVE versions before switching production. As of October 2026.
Contents
- 1. Record dependencies and rollback
- 2. Export a VM through Prism Central
- 3. Import OVF or disks into Proxmox
- 4. Verify the guest and network in isolation
- 5. Agree cutover and operations
- Sources
1. Record dependencies and rollback
Inventory VMs, disks, boot mode, network mappings, guest drivers and application dependencies. Nutanix Files, Objects and Volumes are separate data services and are not automatically replaced by importing a VM. Record their target systems separately. Check application support, backups and recovery as well as acceptable interruptions.
The platform comparison is available under Nutanix alternative Proxmox.
2. Export a VM through Prism Central
Prism Central documents Export as OVA with QCOW2 or VMDK disks. First check whether your version and VM support the process. Establish a consistent application data state and export a scoped test VM first. Download the resulting archive and check completeness and secure transfer. For this guide’s final export, we recommend a controlled guest shutdown after the agreed write freeze. The test export establishes which export options your Prism version actually provides. See the Nutanix Prism Central Infrastructure Guide.
3. Import OVF or disks into Proxmox
Extract the OVA archive in a suitable working directory. Inspect the OVF descriptor and disk files. Proxmox documents qm importovf and separate disk imports. Use VM IDs, storage IDs and paths from your actual environment; this guide does not prescribe production IDs. See Proxmox VM import.
The documented OVF command has the following form. NEW_VMID, the path and storage are placeholders; replace them with a free ID and verified target values before execution:
qm importovf NEW_VMID /path/to/vm.ovf TARGET_STORAGE
OVF import creates a new VM and imports its disks. Networking must be mapped manually. If only a separate disk image is available, create a suitable empty target VM, import the disk through the documented disk import and attach it to the intended controller and boot order. An imported but unattached disk does not yet form a bootable VM. Check target storage and sufficient free capacity before starting the import. See the official Proxmox VM import source document.
Retain the export and source system until acceptance. Importing a file does not automatically transfer every Prism setting.
Disk import and rework. If only a disk image exists instead of an OVF, create the target VM, import the disk and attach it as the boot drive. The example shows a UEFI Linux guest (IDs, names, bridge and VLAN are placeholders):
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 # UEFI guests only
qm set 150 --agent enabled=1
For BIOS guests --bios ovmf --machine q35 and the EFI disk are omitted. The imported disk first appears as "unused" and is connected to the controller only by qm set. Check an already imported OVF result with qm config 150.
| Guest | Rework after import |
|---|---|
| Linux | The kernel usually brings the needed VirtIO drivers; switch controller and network card to VirtIO, install the guest agent (qemu-guest-agent) |
| Windows | Install the VirtIO drivers before switching from SATA or IDE to VirtIO, otherwise the guest does not boot; use the guest agent and driver ISO from the Proxmox ecosystem |
| Both | Remove the Nutanix Guest Tools (NGT) if installed and adapt network interfaces in the guest configuration to the new names |
4. Verify the guest and network in isolation
Compare CPU, RAM, BIOS/UEFI, boot order, disk controllers and network adapters with the inventory. Map bridges and VLANs deliberately. Check VirtIO drivers and the guest agent for the operating system. Initially start the imported guest in isolation so duplicate IP addresses or active application instances do not conflict.
Document boot, disks, networking, services and application tests. The KVM foundation of AHV and Proxmox QEMU/KVM VMs do not replace acceptance. Successful boot is not proof of complete data consistency.
| Check | Evidence to record |
|---|---|
| Boot and disks | Firmware, boot disk, recognised volumes and drivers |
| Networking | MAC/IP mappings, VLAN, DNS and connectivity to dependencies |
| Application | Business functionality checks and a consistent data state |
| Rollback | Abort criterion, responsible person and handling of new target data |
This list proposes acceptance checks. Windows and Linux guests each need driver and operating system checks; the Proxmox VM documentation covers controllers, firmware and the guest agent.
5. Agree cutover and operations
Define write freeze, final consistent export, switchover, business acceptance and rollback criteria. Source and target must not write to production independently at the same time. Data volume and application determine the process; this guide makes no general duration or downtime commitment.
Then plan backups and a restore test. Managed Proxmox covers the agreed target operations; scope and responsibilities are defined for the target system.
Agree migration and target operations: Nutanix migration with WZ-IT connects AHV inventory and migration planning. Managed Proxmox covers agreed subsequent operations.
