Migrate from Nutanix to Harvester: what the move involves
Migrating from Nutanix to Harvester means exporting AHV virtual machines as OVA files from Prism Central, importing them through the vm-import-controller add-on, and validating each workload after it boots on Harvester. The effort depends mainly on the number of VMs, the guest operating systems they run, and whether the existing Nutanix nodes can be reused as Harvester hosts. Teams usually start this work when a Nutanix renewal, a change in term or licensing, or a data residency requirement forces a decision on the platform. This page covers the migration steps only. It does not cover Nutanix pricing, and the cost comparison sits on its own sibling pages.
The platform engineers who do this work need Kubernetes, KubeVirt and Longhorn skills, because Harvester runs VMs on KVM inside Kubernetes and stores their disks in Longhorn. Application owners must confirm that each workload survives the move, including its network identity, storage layout and boot mode. Before any import, check the Harvester hardware requirements for production against the reused Nutanix nodes, especially CPU core count, memory, disk IOPS and 10 Gbps networking, since the Harvester README sets these as minimums. Enable the vm-import-controller add-on first, and plan scratch storage as the Harvester VM import documentation describes. Confirm the guest tools status for each VM, because the controller forces power-off after 60 seconds by default unless the VM shuts down gracefully.
Plan for a pilot batch of non-critical VMs, a rollback path for each workload and a clear cutover window agreed with the application owners. Ask your Harvester support provider to confirm which components your subscription covers and which need separate entitlements, such as Longhorn usage or Rancher, before you size the cluster. Risk concentrates in the workloads that rely on Nutanix-specific guest tools, firmware settings or storage features, so inventory those first. A written scope with named owners, a test plan and acceptance criteria will do more to control the project than any estimate of duration you receive before the inventory is complete.
Which Nutanix capabilities map to Harvester, and which need rework
This table maps the main Nutanix AHV capabilities to their Harvester equivalents and marks each as clean, needs rework or gap. Read the status column first, then the notes, to see where VM moves are straightforward and where network, storage or Prism-specific tooling needs planning. Items tied to Nutanix Move, Flow and Guest Tools are flagged for confirmation in your own environment.
| Capability | Harvester equivalent and status | What to plan or confirm |
|---|---|---|
| VM lifecycle (create, edit, clone, delete) | Clean: Harvester README lists these operations for VMs on KubeVirt and KVM | Rebuild VM templates and cloud-init data for Harvester; AHV-specific settings need review |
| Live migration | Clean: Harvester README describes live migration to another node with zero downtime | Confirm that the guest drivers and CPU settings you use support live migration between your node models |
| VM backup targets | Needs rework: backups go to NFS, S3 or NAS targets, which differ from Nutanix backup policies and snapshots | Recreate backup schedules, retention and restore tests; confirm which Nutanix snapshot or replication features you depend on |
| Distributed storage | Needs rework: Longhorn provides distributed block storage and tiering on the same nodes, replacing Nutanix Data Services | Re-plan replica counts, disk layout and the 5,000 random IOPS per SSD or NVMe disk minimum in the README before migration |
| Multiple NICs and virtual IP networking | Clean for VM NIC attachment and virtual IP addressing as listed in the README | Map VLANs, bonds and management networks by hand; confirm how your switch configuration carries over from AHV networks |
| Monitoring and logging | Needs rework: Grafana and Prometheus ship with the v1.9 architecture | Rebuild dashboards and alerts that relied on Prism metrics; confirm retention and alert routing with your team |
| Prism Central management | Gap: Harvester has its own UI and Kubernetes-based API, with Rancher integration for container workloads | Prism Central dashboards, RBAC groups and automation do not transfer; plan new access roles and confirm the Rancher scope you need |
| Nutanix Move workflows | Gap: Move is a Nutanix tool for migrating into AHV, not a Harvester feature | Confirm with Nutanix whether Move-based steps are still needed for your export path; the OVA route is covered in the migration guide |
| Flow network policies | Gap: no direct equivalent is listed in the Harvester sources reviewed here | Inventory Flow rules and confirm the replacement with Harvester networking documentation and your security team before cutover |
| Nutanix Guest Tools removal | Needs rework: guest tools must be removed from imported VMs and replaced with the drivers your guests need | Confirm the removal steps and guest agent requirements for each OS in your environment before import |
What data and integrations move, and what you rebuild
The documented route out of Nutanix for this move is OVA export from Prism Central, and what travels through it is the VM disks, the virtual hardware configuration and the guest data on those disks. Everything that lives outside the VM is a separate piece of work. Before any export, inventory each VM class (Windows and Linux servers, databases, appliances with licensed or hardware-bound features) and run a test export and import for one VM of each class. Confirm in your own environment that boot mode, disk controller type, NIC model and guest tools behave as expected after import, because Harvester's vm-import-controller only moves what the OVA describes and the guest OS may still need driver or agent changes. Ask your Harvester partner or SUSE to confirm which OVA attributes the controller maps for your VM types.
Identity and access tied to Prism do not move with the VMs. Prism Central role assignments, directory bindings and any local administrator accounts must be recreated on the Harvester side, which uses Kubernetes RBAC and Rancher integration for access. Network VLAN definitions also need to be rebuilt as Harvester networks and mapped to the VMs during import, so the VLAN IDs and uplink assignments should be written down before cutover. Backup jobs are a full rebuild: Harvester writes VM backups to NFS, S3 or NAS targets, so every Nutanix protection policy needs a matching target, schedule and retention set, and restore has to be tested from those new targets. Monitoring dashboards and alerts built on Nutanix metrics must be recreated in Grafana and Prometheus, and any script, Terraform or CMDB integration that calls Nutanix APIs must be rewritten against Harvester's interfaces.
How a Nutanix to Harvester migration runs, step by step
This sequence moves AHV workloads onto Harvester in controlled stages, so each VM, node and network mapping is checked before production traffic depends on it. Each step ends with a written record the next step relies on.
Inventory VMs, guest OS and dependencies
Export a list from Prism Central of every VM with its vCPU, memory, disk sizes, attached networks, guest operating system and owning application. Mark which VMs have Nutanix Guest Tools installed, which use UEFI or legacy BIOS, and which depend on each other. Your team owns this work, with application owners confirming criticality. The output is a verified inventory list with a wave assignment for each VM, and the step is done when every application owner has signed off their rows.
Check reused Nutanix nodes against Harvester minimums
Compare each node you plan to reuse with the Harvester README's production requirements: x86_64 CPUs with hardware-assisted virtualization, 16 cores or more, 64 GB of memory or more, 500 GB or more of disk with at least 5,000 random IOPS per SSD or NVMe disk, and 10 Gbps networking. Nested virtualization and laptop-class hardware are not officially supported. Record the results per node, and confirm with the Harvester project or SUSE which hardware is covered by your support entitlement. The output is a hardware report that marks each node as eligible, eligible with changes or excluded.
Enable the vm-import-controller add-on
Enable the vm-import-controller add-on in Harvester before any import begins, using the steps in the Harvester v1.9 VM import documentation. Confirm the controller is running, that the target storage class and networks exist, and that the import source connection works from the cluster. Your platform engineers perform this step on a test cluster first. The output is a dated configuration record listing the Harvester version, add-on state, storage classes and network names used for import.
Build the import runbook and network mapping
Write a runbook that covers OVA export from Prism Central, transfer to a location the import controller can read, scratch storage sizing, network mapping from Nutanix subnets to Harvester VLAN networks, and the shutdown behavior for each VM. The Harvester docs recommend scratch storage of about twice the largest VM being migrated, and VMs without guest tools need either a forced power-off or a manual shutdown. The output is an approved runbook with a rollback procedure for each wave.
Pilot with non-critical VMs
Import a small set of non-critical VMs that cover your main operating systems and disk layouts. Boot each one, confirm network connectivity, storage performance, drivers and guest agent behavior, and check backup and restore on Harvester. Adjust the runbook for every issue found. The output is a pilot report listing each VM, its import result, the fixes applied and the open defects, and the step closes when the application owners accept the results.
Run in parallel with backups and validation
Keep the Nutanix source VMs available while the imported copies run in Harvester. Take backups of both sides, compare application behavior, performance and data integrity, and document any differences. Validate that live migration within Harvester works for the workloads that require it. The output is a validation sign-off per VM that lists the tests run, the results and the named approver, and no production traffic moves until that sign-off exists.
Cut over in waves
Move production VMs in the waves defined in the inventory, one wave at a time, with a rollback window before the next wave starts. Redirect DNS, load balancers and monitoring to the Harvester copies as each application is switched. Keep Nutanix sources powered off, not deleted, until the wave is stable. The output is a cutover record for each wave showing timestamps, owners, issues and the rollback decision.
Decommission Prism components and keep records
After the last wave is stable and retention requirements are met, shut down Prism Central, Prism Element and the AHV nodes that are no longer used, and remove their access and backup jobs. Confirm with your compliance team which logs and records must be kept, and confirm with Nutanix the terms of any remaining subscription. The output is a decommission record that lists each system retired, the data retained, the access removed and the approver for each item.
What drives the cost and duration of the move
This table lists the cost components of moving AHV workloads to Harvester, who is paid for each, and whether it is one-time or recurring. Use it to see which drivers grow the bill and which items belong in a written quote.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Discovery and inventory | Internal platform team or a implementation partner | One-time | VM count, dependencies between VMs, and the number of undocumented workloads found in Prism Central |
| Hardware reuse or purchase | Hardware vendor or internal budget owner | One-time, plus refresh cycles | Whether reused Nutanix nodes meet the 16-core, 64 GB, 500 GB and 10 Gbps minimums in the Harvester README; confirm CPU virtualization support and SSD or NVMe IOPS on each node |
| Harvester build and networking | Internal engineers or a partner under fixed scope | One-time | Number of VLANs and NIC bonds to map, and whether the cluster needs virtual IP or multiple NIC networks |
| Scratch storage | Storage or infrastructure team | One-time for the migration window | The VM import docs recommend scratch storage of about twice the largest VM being migrated, so the largest disk sets the minimum capacity |
| Import and validation labor | Migration engineers and application owners | One-time per wave | OVA export time from Prism Central, VMs without VMware Tools that need forcePowerOff or a manual shutdown, and the number of application tests per workload |
| Longhorn and SUSE support decisions | SUSE for Harvester subscriptions, if chosen | Recurring | SUSE's support matrix says Longhorn carries a usage-based entitlement and Rancher Manager or guest Kubernetes needs a separate entitlement; ask for both in the quote |
| Training and staff time | Internal staff and training providers | One-time, then ongoing for new hires | Existing Kubernetes and KubeVirt skills, and whether operators already run Prometheus and Grafana |
| Parallel-run period | Operations team and infrastructure costs | One-time, but duration sets the cost | Length of time both AHV and Harvester clusters run, which the Nutanix renewal date and cutover plan control |
What usually goes wrong and how to prevent it
Most failed Nutanix to Harvester moves do not fail inside the import itself. They fail earlier, on reused hardware that falls short of Harvester's production minimums, or later, when the parallel run, network mapping or support contracts were not planned. Each card below names one risk and the check that prevents it.
Reused nodes below minimums
Nutanix nodes are often reused for Harvester, but Harvester's README sets production minimums of x86_64 CPUs with hardware-assisted virtualization, 16 cores or more, 64 GB of memory or more, 500 GB or more of disk with at least 5,000 random IOPS per SSD or NVMe disk, and 10 Gbps networking. Laptops and nested virtualization are not officially supported. Compare each node's core count, memory, disks and NICs against these figures before ordering the cutover plan, and benchmark the disks, since capacity alone does not show IOPS.
Undersized scratch storage
The vm-import-controller needs scratch storage to convert exported OVA disks before they land in Harvester. Harvester's VM import documentation recommends scratch space of about twice the largest VM being migrated. Size the scratch volume against your biggest guest, not your average one, and confirm it has room for the full conversion before starting the first batch, so a single large VM does not fail mid-import.
Forced power-off of running guests
During import, the controller attempts a graceful guest shutdown and forces power-off after a default of 60 seconds. Guests with slow shutdown scripts, open database writes or no guest tools can lose data or boot with a dirty filesystem. Stop application tiers yourself in the correct order, confirm the guest agent is installed on each source VM, and set forcePowerOff only for VMs where you have verified that a hard stop is acceptable.
Network mapping errors after import
Imported VMs keep their original MAC and IP assumptions, but the Nutanix subnets they used do not exist in Harvester. A VLAN or bridge mapped to the wrong network leaves a VM running but unreachable, or places it on a segment that bypasses firewall rules. Build a table that maps every Nutanix network to a Harvester VLAN network before import, then test each VM's reachability and DNS resolution on its new network before retiring the old one.
Backup gaps during the parallel run
While Nutanix and Harvester run side by side, a VM may be protected in one platform and not the other, or changes made on the source after export may be lost when the import is the copy that goes live. Define which copy is authoritative for each VM, freeze changes on the source at cutover, and confirm that Harvester VM backups to an NFS, S3 or NAS target run and restore successfully before decommissioning Nutanix protection.
Support entitlement gaps
SUSE's support matrix says a Harvester subscription covers the bundled appliance components, but Longhorn carries a separate usage-based entitlement, and Rancher Manager or guest Kubernetes needs its own entitlement. Teams that assume one subscription covers the whole stack can find storage or cluster tooling unsupported after go-live. Ask SUSE or your reseller to list each component, its entitlement type and its metric, and compare that list against the Nutanix terms you are leaving.
How the migration changes by estate size and starting point
A small estate of a few hosts and a handful of VMs is the simplest case for Harvester, because the cluster can be built on spare hardware while AHV keeps running. The main work is planning the export and import order, not the platform itself. Start by inventorying each VM in Prism Central, noting its guest OS, disks, NIC count and whether it has Nutanix guest tools installed, then move low-risk VMs first so the team learns the import behavior on its own images.
- Build a parallel cluster first: Install Harvester on hardware that meets the production minimums in the README, so the source estate is not touched during the trial.
- Pilot with one non-critical VM: Export it as OVA, import it, and confirm boot mode, network attachment and disk performance before scheduling the rest.
- Size scratch storage for the largest VM: The import docs recommend scratch space of about twice the largest VM being migrated, so check the biggest disk before starting.
- Plan shutdown behavior per VM: The controller tries a graceful guest shutdown and forces power-off after 60 seconds by default, so schedule maintenance windows for application-consistent stops.
- Decide support before cutover: Confirm whether community releases are acceptable for this estate or whether a SUSE Virtualization entitlement is needed.
Before you finish, confirm the Nutanix renewal end date so the parallel run and the rollback window fit inside your contract.
A larger hyperconverged estate changes the plan because the Nutanix nodes themselves may become Harvester nodes. Harvester brings its own storage stack, Longhorn, so the Nutanix storage layer has to be drained and removed from each node before the hardware is repurposed. This makes sequencing node by node essential, and it means the source VMs must be exported or moved to other capacity before a host is rebuilt.
- Check each node against the production minimums: Verify x86_64 CPUs with hardware-assisted virtualization, core count, memory, disk size, the SSD or NVMe IOPS target and 10 Gbps networking on every node you plan to reuse.
- Keep enough capacity to evacuate: Free enough headroom on the remaining nodes to hold VMs while one node is rebuilt, since Nutanix storage must be retired first.
- Map networks before the first import: Design the VLANs and bonds that Harvester will use, so each imported VM lands on the correct network.
- Rebuild in waves: Repeat the drain, wipe, install and verify cycle node by node, and keep a rollback path until the cluster passes a full workload test.
- Confirm storage replication settings: Set Longhorn replica counts and tiering deliberately, because they replace the data protection you had under Nutanix.
Ask your Harvester partner or SUSE contact to confirm how Longhorn sizing maps to your Nutanix node specification.
A team that already runs Kubernetes will look at Harvester as a way to place KubeVirt virtual machines next to containers under one control plane. The migration itself is the same OVA export and import, but the operating model shifts toward Kubernetes objects, namespaces, RBAC and GitOps workflows. Plan this as both a platform migration and a skills change, so the cluster is not treated as a generic hypervisor.
- Decide which workloads move as VMs: Keep stateful or licensed appliances as VMs and move stateless services to containers, so the VM count stays limited to what needs it.
- Integrate with Rancher where it helps: The README describes Rancher integration for managing Harvester together with containerized workloads, so confirm whether your existing Rancher setup fits.
- Account for separate entitlements: SUSE's support matrix says Rancher Manager or guest Kubernetes needs its own entitlement, so budget for it separately from Harvester support.
- Define namespace and network policy early: Map VM networks to Kubernetes networking models before importing, since changing them later affects running workloads.
- Automate the import and verification: Script the export, import and checks so the team can repeat them, and record the VM definitions in version control.
Review the Harvester v1.9 VM import documentation with your platform team before writing the first pipeline.
A team that needs commercial support for its hypervisor layer will evaluate SUSE Virtualization, the supported Harvester product that is part of SUSE Rancher Prime. The sequencing choice here is whether to deploy a community release or a Prime release, because support windows and entitlements differ. Make this decision before the production build, since changing release lines later means another upgrade cycle.
- Check the support matrix for your version: SUSE's matrix lists v1.8.0 as a Community release and v1.8.1 and v1.8.2 as Prime releases, with end of maintenance on December 29, 2026 and end of life on December 29, 2027.
- Understand what the entitlement covers: A Harvester entitlement covers bundled components such as the host OS, Longhorn, the cloud provider and CSI driver and the Terraform provider.
- Price Longhorn separately: Longhorn carries an additional usage-based entitlement, so storage growth affects support cost.
- Plan upgrades inside the window: Schedule upgrades so the cluster stays on a supported line through the migration and beyond.
- Request a written quote from scope: Ask SUSE or a reseller to itemize the bundled and separately licensed components for your node count and storage size.
Confirm with SUSE which release line and entitlements apply to your estate before signing a support contract.
Questions buyers ask before moving from Nutanix to Harvester
What drives the cost and effort of moving from Nutanix to Harvester?
The cost is mostly labor and hardware readiness, not software licensing, because Harvester is Apache-2.0 licensed and has no per-core fee for the platform itself. The main cost components are the people who plan and run the migration, the time to export and import each VM, scratch storage, any hardware added to meet Harvester's requirements, staff training on Kubernetes and KubeVirt, and optional support. Effort rises with the number of VMs, their size, how many have guest tools or custom drivers to remove, and how many need network redesign. Ask any implementation partner for a written scope that lists VM counts, sizes, network mappings and test criteria before accepting a quote. Ask SUSE for current Harvester subscription terms if you plan to buy support.
How long does a Nutanix to Harvester migration take?
The duration depends on the number and size of VMs, the speed of OVA export and import, how many workloads need re-testing, and how much of the cluster must be built before any VM moves. The Harvester VM import documentation notes that the controller first attempts a graceful guest shutdown and then forces power-off after a default of 60 seconds, so each VM needs a planned outage window. Migration waves are usually sized around business-critical applications, which lengthens the schedule. No fixed duration applies to your estate, so ask for a timeline in writing that is tied to the agreed scope and to your Nutanix renewal date.
Can our in-house team migrate from Nutanix to Harvester without a partner?
Yes, a capable team can do it, but the skills required go beyond hypervisor administration. Operators need working knowledge of Kubernetes, KubeVirt, Longhorn storage and the Harvester architecture, which uses Elemental for SUSE Linux Micro 6.2 as the host OS, along with Prometheus and Grafana for monitoring. Teams without that experience should budget for training or outside help during design and the first waves. Confirm whether your staff can handle cluster design, backup, upgrades and incident response after go-live, since those tasks recur long after the migration ends.
What must our team provide before the migration starts?
Your team must supply an accurate inventory of VMs, their operating systems, disks, network needs and owners, plus the maintenance windows and acceptance tests for each application. You also need access to Prism Central to export VMs as OVA, enough hardware and network capacity for scratch storage, and named people who can approve cutover and rollback decisions. Plan for scratch storage of about twice the size of the largest VM being migrated, as the Harvester documentation recommends. Confirm the required access, ticketing and change-control steps with whoever will run the work.
Can we reuse our existing Nutanix nodes for Harvester?
Possibly, but only if each node meets Harvester's production requirements. The Harvester README calls for x86_64 CPUs with hardware-assisted virtualization and 16 cores or more, 64 GB of memory or more, 500 GB or more of disk with at least 5,000 random IOPS per SSD or NVMe disk, and 10 Gbps networking. Laptops and nested virtualization are not officially supported. Check each node's CPU, memory, disk performance and NIC speed against these figures, and confirm that existing Nutanix hardware is supported for reuse, since your Nutanix hardware may be tied to Nutanix firmware or support. Also verify how Longhorn will use the local disks, because storage layout changes significantly when Nutanix storage is removed.
Do we need SUSE Virtualization support, and what does it cover?
Support is optional, and the decision rests on your risk tolerance and staffing. SUSE Virtualization is the commercially supported Harvester product and is part of SUSE Rancher Prime. According to SUSE's support matrix, v1.8.0 is a Community release, while v1.8.1 and v1.8.2 are Prime releases, with end of maintenance on December 29, 2026 and end of life on December 29, 2027. A Harvester support entitlement covers bundled components such as the host OS, the cloud provider and CSI driver, and the Terraform provider. Longhorn carries an additional usage-based entitlement, and Rancher Manager or guest Kubernetes needs a separate entitlement. Ask SUSE for a written quote that lists each component, and check which release line you plan to run.
How do cutover and rollback work for VMs moved to Harvester?
Cutover is handled one VM or group at a time, and each source VM stays intact on Nutanix until the target passes acceptance tests. Plan the sequence so each VM is exported as OVA from Prism Central, imported through the vm-import-controller add-on, tested, and then switched over during its window. Rollback means keeping the Nutanix source available and retaining its last good state until the business signs off, so a failed VM can start again on AHV. Because the import controller forces power-off after the default 60 seconds if the guest does not shut down, confirm guest shutdown behavior in advance. VMware-style guests without VMware Tools need a forcePowerOff setting or a manual shutdown, so verify the approach with the platform documentation and your own test environment before production waves.
How DeployOpen scopes and runs a Harvester migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where the Nutanix nodes already run. For a move from AHV to Harvester, the first scoping step is an inventory of the VMs to be exported from Prism Central, the Nutanix nodes to be reused, the network and VLAN layout, and the applications with vendor-specific guest tools or firmware settings. Ask for that inventory to be written into the scope document, because it determines the import waves, the scratch storage sizing and the cutover order.
Engagements are usually fixed-scope, so scope, deliverables, acceptance criteria and timelines are agreed in writing before work starts. A written scope for this migration should name the hardware check against the Harvester README requirements, the enabled vm-import-controller add-on, the import method and its shutdown behavior, the target network mapping, the backup target and the rollback plan for each wave. Ongoing support, upgrades and continuous testing are available as retainers, which matters because Harvester releases move quickly and Nutanix subscriptions may still be running during the transition. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for line items that separate one-time migration work from any recurring retainer.
Where a client needs compliance evidence, DeployOpen prepares systems, controls and evidence for an assessment, such as configuration records, backup test results and change logs. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Confirm with your assessor which evidence they expect before the migration starts, and agree in the scope which artifacts DeployOpen will hand over at each stage. SUSE Virtualization subscriptions are a separate decision from the implementation scope and should be confirmed directly with SUSE.
