How to export your data from Nutanix

How to export your data from Nutanix before your term ends

If your Nutanix term is ending or you are deciding whether to leave AHV, the first task is to confirm how VM disks and configurations can be moved out of the platform. The supplied sources do not document the Nutanix export steps, so you should confirm the exact procedure in Nutanix's own documentation for your AOS and Prism Central versions before planning a cutover. Treat that confirmation as the first gate in the project, because every later step depends on which formats and tools Nutanix supports for export. Nutanix Move is the tool to check first, but be clear about its direction. The Nutanix Move 6.0 announcement of September 16, 2025 describes Move as migrating VMs to Nutanix AHV from VMware ESXi, Hyper-V and public clouds, which is an inbound path. Do not assume Move will extract workloads from AHV. Ask your Nutanix account team in writing whether any supported export route exists for your estate, and what it requires, including whether guest tools must be removed first and whether disks must be exported individually or as an archive.

Once you know what Nutanix can export, the target platform sets the import requirements. Proxmox VE documents import paths through its own wiki, including OVF import with qm importovf, disk import for VMDK files with qm disk import, and Clonezilla as an alternative, and its ESXi import wizard is a separate path that does not apply to AHV exports. XCP-ng documents its own migration paths in the Migrate to XCP-ng documentation, and you should verify which formats its import tooling accepts before you commit. Run a pilot with one non-critical VM from each guest operating system family, then check firmware mode (BIOS or UEFI), disk controller type, network adapter model and any Nutanix guest tools left in the image. Record each result, because these settings decide whether a restored VM boots without manual repair.

Which VM data can leave Nutanix and which import paths the target platforms document

This table compares each kind of Nutanix VM data with the export method, the target format and the import path that each candidate platform documents. Read it as a checklist: the Nutanix export side needs confirmation in Nutanix documentation, while the import side is documented for VMware sources, so most AHV exports need a format conversion step before the import tools accept them.

Data type	Export or import method	Target format	Limits to check
VM disks and configuration from AHV	Export as OVA from Prism Central (confirm the export steps and supported VM types in Nutanix documentation)	OVA package containing OVF descriptor and VMDK disks	Confirm OVA export is available for your Prism Central version and VM configuration
Proxmox VE import wizard	Built-in wizard for ESXi and vCenter sources, added in Proxmox VE 8.2	Imported directly from VMware sources, not from AHV exports	Documented for ESXi 6.5 to 8.0 only; vSAN-backed disks cannot be imported
Proxmox VE alternative paths	OVF import with qm importovf, qm disk import for VMDK files, or Clonezilla	OVF and VMDK disks into Proxmox VE storage	Snapshotted VMs import more slowly; verify disk bus and boot settings after import
XCP-ng with Xen Orchestra V2V	Warm migration from ESXi 7 and later over HTTP access to the ESXi API	Xen disk images on an XCP-ng storage repository	ESXi 6.x hosts are not supported for V2V; AHV exports need a separate import route
XCP-ng documented imports	Import paths documented for Hyper-V, KVM and VirtualBox sources	XCP-ng virtual machines	No AHV import path is documented; confirm conversion from OVA or raw disks with Vates
Harvester vm-import-controller	Add-on that imports VMs from VMware and OpenStack sources	KubeVirt VM objects on Harvester	Documented for VMware and OpenStack only; confirm the OVA route from AHV exports before planning
Disk format conversion step	Convert exported disks with a standard tool such as qemu-img before import (illustrative)	Raw, qcow2 or VMDK as the target platform requires	Check checksums and boot a test copy before cutover
Guest drivers and firmware	Review BIOS or UEFI mode and remove Nutanix guest tools after import	Settings on the target VM definition	Mismatched firmware is the most common reason an imported guest fails to boot

What does not move with the VM and how to handle it

A VM export carries disks and basic virtual hardware, but much of what makes a Nutanix estate operate lives outside the guest. The four items below typically need their own handling during an export and import, and each one should be inventoried before the first VM leaves AHV.

Prism management settings and dashboards

Prism Central holds categories, alert policies, role mappings, dashboards, saved reports and network and storage definitions. None of these travel inside an OVA. Recreate the parts you still need on the target: rebuild the network mapping, storage pools and access roles in Proxmox VE or XCP-ng, and rewrite any alert or reporting rules in the monitoring stack you choose. Export a written inventory from Prism Central first so nothing is lost by memory. Confirm with Nutanix exactly which objects Prism exposes for export, and confirm the equivalent configuration model on your target platform.

Nutanix Files and Objects data

Shares and buckets served by Nutanix Files and Nutanix Objects are separate data services, not disks attached to a VM. An OVA or disk export of a VM that mounts a share copies only the VM's own disk, so the share contents need a separate file-level copy. Map each share to a destination, copy the data with a tool that preserves ownership and timestamps, and verify checksums on a sample before cutover. Permissions tied to Active Directory identities may need re-mapping. Confirm with Nutanix how Files and Objects expose data for bulk copy, and confirm how your target platform will serve it.

Nutanix guest tools and drivers

Nutanix VirtIO drivers and the Nutanix guest tools installed inside Windows and Linux guests are tied to AHV. After import, the guest may still expect those components, and removing them is safer than leaving stale agents behind. Plan to reinstall the drivers appropriate for the target hypervisor, such as VirtIO drivers for KVM on Proxmox VE, and verify network and disk recognition in a test clone first. Firmware mode is a separate check: confirm whether the guest boots as BIOS or UEFI and match the target settings after import. Confirm the exact driver and agent steps with Nutanix and your target platform's documentation.

Snapshot and replication history

Nutanix snapshots and replication schedules do not come across as usable history on the target. Proxmox documents that VMs with snapshots import more slowly, so consolidating or deleting unneeded snapshots before export shortens the copy and avoids importing state you do not want. Record your recovery point objectives and keep a final backup set from the source before the cutover. Replication targets must be rebuilt on the new platform, for example with Proxmox Backup Server. Confirm with Nutanix how snapshots appear in an export, and confirm the snapshot and backup behavior of your target platform.

Choosing the import path for Proxmox VE or XCP-ng

Proxmox VE offers several import routes, and the right one depends on what your export produces. The integrated import wizard, added in Proxmox VE 8.2, was built for VMware ESXi and vCenter sources, and Proxmox documents testing from ESXi 6.5 to 8.0. Treat that range as the tested scope of the wizard and confirm any other source format before you rely on it. For an OVA exported from Prism Central, the command-line paths are usually the more direct choice.

Import wizard: Maps most of the original configuration when the source is ESXi or vCenter. Confirm with a test export whether it reads your Nutanix package or whether you need a command-line path.
qm importovf: Imports an OVF package as a new VM. Unpack the OVA into OVF and disk files in a test directory before running it.
qm disk import: Imports VMDK or other disk images into an existing VM, which helps when you rebuild the VM definition by hand.
Clonezilla: Proxmox lists disk imaging with Clonezilla as an alternative path, so keep it in reserve for guests the other routes cannot handle.
Known limits: vSAN-backed disks cannot be imported, and VMs with snapshots import more slowly, so remove or consolidate snapshots before export where your process allows.

Before scaling up, test one VM from export to boot: confirm the disk controller, network mapping and boot mode, then check the firmware and driver settings on the imported guest.

The complete export sequence and the checks at each step

This sequence moves Nutanix AHV virtual machines to an open-source target in controlled stages, so each VM is proven bootable and working before its source is retired. Each step closes with a recorded check or output, so the team can show what moved, what was tested and what was kept as a backup.

Inventory VMs and their dependencies
The platform team works with application owners to list every VM with its operating system, boot mode, disk count and sizes, network interfaces and VLANs, installed guest tools, attached storage, backup jobs, DNS entries, licensed software tied to hardware and required startup order. Group the VMs by application so related systems move together. The output is an inventory sheet that each application owner signs off on before any export begins.
Confirm export method and format
Check the current Nutanix documentation for your Prism Central and AOS versions to confirm which VMs can be exported, the export format offered, and whether the resulting disk files can be imported by your target platform. Ask your Nutanix account team or support to confirm anything the documentation leaves open, including limits on VM size and guest operating systems. The output is a short written record of the method, format and versions, kept with the migration plan.
Consolidate snapshots before export
Delete or merge existing snapshots on each VM after confirming that a current backup exists. Quiesce databases and stop write-heavy services where the application requires it, so the exported disk reflects a consistent state. Proxmox documents that VMs with snapshots import more slowly in its ESXi import path, which is a useful signal to clear them before moving any VM. The output is a list showing zero snapshots on every VM in scope.
Export and import a pilot VM
Choose one non-critical Linux VM and one non-critical Windows VM as pilots. Export each as an OVA from Prism Central, copy the file to staging storage on the target, and import it with the OVF import path (qm importovf) or by importing the disk with qm disk import, both described in the Proxmox migration guide. Attach the disk, set the boot order and start the VM. The output is a pilot VM that starts on the target and shows its console.
Check boot mode, disks, network and drivers
Confirm that the firmware setting on the target matches the source, either BIOS or UEFI, and add an EFI disk if the VM expects UEFI. Verify the disk controller type, since a changed controller can stop a guest from finding its boot disk. Remove Nutanix guest tools, install the virtio drivers on Windows guests, map each NIC to the correct bridge and VLAN tag, and fix device names or fstab entries on Linux. The output is a per-VM checklist with each item marked as passed.
Run application and restore tests
Application owners run their functional tests on the imported VM, covering logins, database consistency, integrations with other systems, scheduled jobs and a basic performance check against the baseline. Test a restore of the imported VM from a backup on the target, since a VM that boots but cannot be recovered is not ready for cutover. The output is a signed test report for each pilot VM that records the results and any open defects.
Export remaining VMs in verified batches
Export the rest of the estate in batches that follow the dependency groups from the inventory, repeating the export, import and checklist steps for each VM. After each transfer, compare file sizes with the source export and compute SHA-256 checksums on the OVA and disk files, then recompute them after the files are copied to the target storage. The output is a batch log that lists each VM with its file sizes, checksums and test status.
Back up images and retire source VMs last
Store a backup copy of each exported image and its checksum manifest on storage separate from the production target, and keep it until the migration is closed. Power off or set the source VMs to read-only only after the restore tests for that VM have passed, and keep the Nutanix copies for a rollback period agreed in advance with the application owners. The output is a decommission record per VM showing the backup location, the test report and the date the source was retired.

Firmware and driver settings to check after import

The most common failure after an OVA or disk import is a VM that starts from the wrong firmware. A guest built on BIOS may be imported into a target configured for UEFI, or the reverse, and the operating system then fails to find its boot partition. Before you power on any imported VM, compare its firmware type in the source definition exported from Prism Central with the firmware and machine type set on the target. The same check applies to the disk controller (such as SCSI, VirtIO or SATA) and the network adapter model, because an imported guest may not have a driver for the controller the target presents. Record each setting per VM in your cutover runbook so the comparison is repeatable across the estate.

Guest tools and hypervisor drivers installed for AHV are the second risk. Nutanix guest tools and their storage or network drivers were written for the source platform, and leaving them in place can cause services to fail, duplicate devices to appear, or agents to report the wrong host. Plan to remove them from the guest before or immediately after the first boot on the target, then install the drivers and guest agent that the target platform documents for that operating system. Confirm the exact driver package, agent name and supported guest operating systems with the target vendor's documentation, because support for specific Windows and Linux releases differs by platform and version.

Treat the first boot as a test, not a cutover. For each VM, check that it reaches the login prompt, that network connectivity works with the new adapter, that disks mount in the expected order and that time synchronization is correct. Run an application-level check with the owning team, and keep the source VM available until the target has passed. Use the import documentation for your target, for example the Proxmox wiki page on migrating to Proxmox VE, to confirm which firmware and controller options the import path preserves and which you must set by hand. Where your environment has licensed Windows or Linux guests, confirm activation and subscription behavior after the hardware change as well.

What to plan before the Nutanix subscription renews or ends

Your Nutanix term sets the deadline, but the export itself has to be proven before anything is switched off. The four cards below cover the contract, the cutover sequence, the learning-only status of Community Edition, and the licensing choices that follow the move.

Confirm the term and notice window

Nutanix sells Cloud Infrastructure as term subscriptions of 1 to 5 years, licensed on physical CPU cores. Find the exact end date on your order form and the notice period in your agreement or reseller contract. Ask whether the term renews automatically and at what terms, and whether you can run a shorter bridge term while the migration is completed. Ask what happens to your data, backups and access to Prism Central when the subscription lapses.

Keep the cluster running until restores pass

Do not decommission AHV nodes until you have restored at least one representative VM from each export path onto the target platform and booted it. Test the guest network, storage mapping and disk performance, not only whether the file imports. Keep the source cluster and its snapshots available until the restores and your backup tests succeed. Record which VMs have been validated so cutover decisions rest on evidence.

Community Edition is not production

Nutanix Community Edition is a no-cost download positioned for learning and skill development on your own hardware. It is not a supported production edition, so it cannot serve as a landing zone for production workloads or as a support-backed fallback. Use it, if at all, to rehearse commands and workflows in a lab. Plan production capacity on a supported platform, and confirm with your reseller what support you retain during the transition.

Choose Proxmox VE and Vates support

Proxmox VE has the same features in every subscription tier, so the choice is about support entitlements and access to the enterprise repository, not functionality. Subscriptions are priced per CPU socket per year. Vates offers XCP-ng and Xen Orchestra as free software, with paid support plans priced per host. Decide whether you need a vendor-backed support level for production, and get the per-socket or per-host cost into your comparison before the renewal date.

Questions buyers ask before they export from Nutanix

How much effort does a full export from Nutanix take, and what drives it?

Effort scales mainly with the number of VMs, the size of their disks, and how much mapping and testing each workload needs. Start by building a full inventory with CPU, memory, disks, networks and dependencies for every VM. Snapshots add time, since the Proxmox documentation notes that VMs with snapshots import more slowly, so agree with owners which snapshots can be removed before export. Network mapping adds work for each VM that depends on specific VLANs, bridges or fixed IP addresses. Functional testing of boot, drivers and application login often takes more time than the copy itself. Ask for an inventory-based estimate before you commit to any date.

Can our own team export and import the VMs without outside help?

Yes, a small estate run by a team with Linux and virtualization skills can usually do it alone, provided it starts with a pilot. Pick one non-critical VM and run it through the full path: export from Prism Central, import into Proxmox VE or XCP-ng, correct firmware and driver settings, and test the application. The Proxmox migration guide describes alternative import paths, including OVF import with qm importovf, disk import for VMDK files and Clonezilla, which your team can compare during the pilot. Document each step in a runbook so later batches follow the same method.

What does an export project need from our side?

The project needs access, space, time and people from your side. Your administrators need a Prism Central account with permission to export VM images. You need staging storage with enough free capacity for exported images and converted disks, plus a target platform ready to receive them. Schedule maintenance windows for each application, because a VM cannot be tested safely while business teams are using it. Named application owners must confirm that each workload works after import. Finally, provide network details, DNS entries and IP plans for the target environment so that imported VMs can be reconnected correctly.

Do we need a consultant to move workloads off Nutanix?

No, a consultant is not required for a straightforward estate that your team can operate. External help adds value in two places. The first is verification: independent boot tests, application checks and data comparisons confirm that each migrated VM matches its source before users rely on it. The second is cutover planning: sequencing batches by dependency, defining rollback steps and agreeing freeze windows with application owners. DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts.

What should a quote for a Nutanix export include?

A useful quote lists each deliverable and states what the customer provides. Ask for these five parts: a VM and disk inventory with dependencies, a pilot with written success checks, a batch plan that groups VMs by application and maintenance window, a verification method for each batch covering boot, application tests and data comparison, and a handover package with runbooks, rollback steps and documentation. Also ask which costs are one-time, such as migration work, and which recur. Proxmox VE can run without a subscription, so ask whether vendor support is included, optional or excluded. DeployOpen does not publish a price list, and a quote follows from the written scope.

Can we export data from VMs while the Nutanix cluster keeps running?

Yes, the Nutanix cluster can keep serving other workloads while you export selected VMs, but the state of each exported VM needs care. A VM that is still writing data during export may produce an image that is inconsistent, which matters most for databases and other transactional applications. For those workloads, plan a controlled shutdown or a quiesced copy with the application owner, and confirm the export method with Nutanix documentation for your AOS and Prism Central version. Keep the source VM untouched until the migrated copy passes testing, so rollback remains possible. Staging capacity and network bandwidth will set how many exports can run at once.

How DeployOpen works on this

DeployOpen plans and implements the exit from Nutanix AHV inside your own infrastructure, from the OVA export in Prism Central through import, validation and backup. Each engagement starts with a written, fixed scope so the VM inventory, target platform and acceptance tests are agreed before any work begins.

How we scope

Inventory every AHV VM, its disks, NICs, guest OS and the Prism Central export path before choosing a target.
Agree in writing which target platform, such as Proxmox VE or XCP-ng, each workload group moves to.
Confirm with you which VMs need a cutover window, which can be exported offline and which owners sign acceptance.

How we build

Test one representative OVA import end to end, checking firmware mode, disk controller and network mapping before bulk moves.
Remove Nutanix guest tools and adjust drivers, boot settings and virtual hardware on each imported VM.
Set up backups on the target platform and run a restore test before any production VM is switched over.

How we hand over

Deliver a runbook listing each VM, its source, target, import settings and the post-import checks passed.
Document the rollback path for every VM, including keeping the source AHV copy until acceptance is signed.
Provide knowledge transfer to your operations team on the new hypervisor, backups and day-to-day procedures.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask any quote to itemize scoping, migration labor, backup setup and retainer terms as separate lines.

How to export your data from Nutanix