Choose vSphere or Harvester based on whether your estate is VM-only or VM-plus-containers
If your estate is mostly virtual machines and your teams already run VMware operations well, stay with vSphere for now and price the renewal honestly. If you also run Kubernetes and want VMs and containers managed from one control plane, Harvester is the open-source platform to evaluate. The deciding question is not which hypervisor is better in isolation but whether your next three years of work look like VM operations or like platform engineering. vSphere fits when your operations are built around vCenter, when vSAN is already the storage you trust, when backup, monitoring and automation tools are wired to the VMware APIs, and when your staff know ESXi well enough that retraining would cost more than the license. Under Broadcom's current model, vSphere Enterprise Plus, vSAN and NSX are sold only inside VMware Cloud Foundation or VMware vSphere Foundation, so the renewal question is about which bundle you need, not whether to buy the components separately. Harvester fits when Kubernetes teams own the infrastructure, when Apache-2.0 licensing and no per-core fee matter to your procurement, when Longhorn distributed block storage is acceptable for your workloads, and when you want backups to NFS or S3 targets that you already operate.
The decision turns on four things. The first is skills: a Harvester cluster is operated through Kubernetes concepts, KubeVirt and Longhorn, so check whether your team can troubleshoot those layers at 2 a.m. The second is hardware: confirm your servers meet the production minimums listed in the Harvester README, including 16 cores or more, 64 GB of memory or more and 10 Gbps networking, and treat nested virtualization or laptop-class hosts as out of scope. The third is storage: test Longhorn performance against your real VM disk profile instead of assuming it will match vSAN. The fourth is the support model, because the Harvester open-source release and SUSE Virtualization are different entitlements, and Longhorn carries its own usage-based entitlement under the SUSE support matrix. Ask SUSE and your reseller to confirm current terms in writing before you size a contract. A practical next step is to inventory your VMs by type. If most are Windows and Linux servers with vSAN-backed disks and no container roadmap, a vSphere renewal or a move to another platform is likely the cleaner path. If a meaningful share of your workloads will run as containers within the next budget cycle, run a small Harvester proof of concept on hardware that matches the README minimums and import a representative VM set through the vm-import-controller add-on before you commit.
Which platform fits each scenario
This table matches common estate situations to the platform that fits best and the reason, using only the facts this page relies on. Read each row against your own estate, and treat the Harvester column as a fit for a specific shape of environment rather than a general replacement for vSphere.
| Scenario | Better fit | Reason |
|---|---|---|
| VMware-only estate with no containers | Proxmox VE or XCP-ng | Harvester's model is built around Kubernetes, so teams without container plans carry platform complexity they do not need. Proxmox VE and XCP-ng manage VMs directly with a simpler operating model. |
| Team building on Kubernetes | Harvester | Harvester runs VMs through KubeVirt on Kubernetes, so VMs and containers share one control plane, with Rancher integration for containerized workloads. |
| Mixed estate moving in waves | Harvester for container-linked waves, others for pure VM waves | The vm-import-controller add-on covers VMware, OpenStack and OVA sources, but each wave still needs network mapping and shutdown rules. Keep VM-only workloads on the platform that matches their skills. |
| Site without 10 Gbps networking | Proxmox VE or XCP-ng | Harvester's production requirements list 10 Gbps networking, and nested or laptop-class setups are not officially supported. Confirm your site meets the full hardware minimums before choosing Harvester. |
| Team that needs commercial support | SUSE Virtualization, or confirm with Proxmox or Vates | SUSE Virtualization is the commercially supported Harvester product. Its support entitlement covers bundled components, but Longhorn needs a separate usage-based entitlement and Rancher or guest Kubernetes need their own. Ask SUSE for a written quote covering each. |
| Team with limited Kubernetes skills | Proxmox VE or XCP-ng | Harvester operations depend on Kubernetes, Longhorn and KubeVirt knowledge. Confirm the staff time and training your team needs before committing. |
How Harvester stacks Kubernetes, KubeVirt and Longhorn
Harvester runs VMs as Kubernetes objects. The v1.9 documentation lists Elemental for SUSE Linux Micro 6.2 as the host operating system, Kubernetes as the control plane, KubeVirt for managing KVM virtual machines on Kubernetes, Longhorn for distributed block storage and tiering, and Grafana and Prometheus for monitoring and logging. Each layer has its own upgrade path and failure modes, so the cluster is not a single hypervisor you patch in isolation. Before you size a pilot, confirm with SUSE which component versions ship together in the release you intend to run, because the host OS and Kubernetes versions move with each Harvester release.
For operators who know vCenter, the mapping is close but not one to one. Hosts join a Harvester cluster, VMs are created and edited through the Harvester interface or the Kubernetes API, and live migration moves a running VM to another node. The difference is that VM configuration, disks and networks are stored as Kubernetes resources, so the skills that matter shift toward kubectl, namespaces, storage classes and KubeVirt's VirtualMachine objects. Teams without Kubernetes experience should plan training time for those objects before the first production wave, not during it.
For operators who already run Kubernetes, the appeal is one control plane for both VMs and containers. Harvester's README describes integration with Rancher for managing Harvester alongside containerized workloads, so the decision is whether your platform team wants a single management plane for both. Rancher integration is for containerized workloads running alongside VMs, not a replacement for the VM lifecycle tooling in Harvester itself. Confirm with SUSE which Rancher and guest Kubernetes entitlements apply to your design, since those are licensed separately from Harvester.
What Harvester production hardware minimums mean for your rollout
Harvester's README sets minimum hardware for production clusters across CPU, memory, storage and networking. Each minimum changes how many existing vSphere hosts you can reuse and how much you must buy before the first migration wave.
CPU: virtualization and core count
Production nodes need x86_64 CPUs with hardware-assisted virtualization and 16 cores or more. Check each candidate host in your vSphere clusters for the virtualization extensions in BIOS and the core count per node, not per socket. Older hosts that pass in vSphere may still fail this minimum, so record the model and core count for every host in the inventory.
Memory: 64 GB per node
The README asks for 64 GB of memory or more on each production node. Consolidating VMs from a vSphere cluster onto fewer Harvester nodes can push memory use past what a host with a smaller DIMM population can carry. Confirm the installed DIMM capacity, and plan headroom for node failure so the remaining nodes can absorb the VMs from a failed host.
Storage: disks and random IOPS
Each node needs 500 GB or more of disk, with at least 5,000 random IOPS per SSD or NVMe device. Harvester's distributed block storage uses Longhorn, so these disks are shared by every VM in the cluster. Measure IOPS on the candidate drives with your own workload profile, because a spec sheet figure does not show latency under load. Keep vSAN-backed VMs in mind, since their data must be moved to new storage first.
Networking: 10 Gbps links
The README calls for 10 Gbps networking. Live migration and Longhorn replication both generate east-west traffic, so a 1 Gbps management or storage network will slow moves and rebuilds. Check switch ports, cabling and NIC drivers on every node, and confirm that separate VLANs for management, storage and VM traffic can be configured on the links you have.
Unsupported lab and nested setups
Laptops and nested virtualization are not officially supported for production Harvester. A proof of concept on nested vSphere VMs can help test the import workflow, but it cannot show performance, storage behavior or support eligibility. Plan a separate pilot on real hardware that matches the production minimums before you commit any VMs to the platform.
How the vm-import-controller moves VMs from VMware
The vm-import-controller is an add-on that must be enabled before Harvester can import anything from VMware, OpenStack or OVA sources, so the first task is to switch it on in the cluster and confirm it runs before you plan any wave. Its VMware path reads a source VM and recreates it on Harvester, which means the controller needs a working connection to the vCenter or ESXi endpoint you configure. Check the add-on settings and the controller pods on a test cluster first, and confirm the exact enablement steps and source versions against the Harvester v1.9 VM import docs for the version you run, since the add-on is versioned with the platform.
Before copying disks, the controller tries a graceful guest shutdown and forces power-off after a default of 60 seconds. For Linux and Windows guests with VMware Tools, a clean shutdown usually completes inside that window, but databases, large application servers and VMs with long shutdown scripts may not. VMs without VMware Tools cannot be asked to shut down gracefully, so you must either set the forcePowerOff option on the import specification or shut the guest down manually before the import starts. Decide this per VM in your inventory, and agree with application owners that a forced power-off is acceptable for each database or stateful service before scheduling the window.
Plan scratch storage before the first import. The docs recommend free space of about twice the size of the largest VM being migrated, because the controller stages disk data while it converts and attaches it. Size this against your Longhorn or other backing storage, not just the raw capacity of the cluster, and remember that concurrent imports multiply the demand. Confirm the scratch sizing guidance in the version-specific docs, then test one representative large VM end to end so you measure real copy time and downtime rather than estimating them.
Where your data lives under each platform
Under VMware Cloud Foundation or VMware vSphere Foundation, your virtual machines, vSAN datastores and vCenter inventory stay in your own data centers, and the hypervisor licensing does not move data off your premises. The residency question is therefore mostly about who administers the platform and where backup copies and support access sessions go. Broadcom's knowledge base states that hosts on perpetual licenses keep running after Support and Subscription expires, but patch downloads and major upgrades require an active contract, which affects how long you can keep the evidence trail for patch currency.
- Data location: VM disks sit on your datastores, including vSAN, which lives on your hosts.
- Backup destinations: Backups go to products your team chooses, often a commercial backup suite, so confirm where its catalog and copies reside.
- Identity and audit: vCenter roles and logs are yours to export, but confirm how they link to your directory service.
- Support access: Vendor support sessions and log bundles leave the site, so confirm your approval path.
- Patch evidence: Keep records of subscription status and applied patch levels.
Ask your vendor to confirm in writing which telemetry or support data leaves your network under your contract.
Harvester is open-source hyperconverged software under Apache-2.0, built on Kubernetes, KubeVirt and Longhorn, and it runs on hardware you own in your own facility. Virtual machine disks are stored in Longhorn volumes across your nodes, so data residency is the physical location of those nodes. Because the software is self-hosted, no data passes to the project or to SUSE unless you send it there, but your operators still need to control update channels and any support tickets you raise.
- Data location: Longhorn replicas stay on the nodes and disks you deploy in your own site.
- Backup destinations: Harvester documents VM backups to NFS, S3 or NAS targets, so choose targets inside your boundary or an S3-compatible store you operate.
- Identity and audit: Access is managed through Kubernetes and Harvester roles, so connect your identity provider and retain Kubernetes audit logs centrally.
- Monitoring data: Grafana and Prometheus keep metrics and logs on the cluster, so set retention and storage locations deliberately.
- Update source: Confirm which release channel you pull images from and mirror it internally if the site is isolated.
Confirm the backup target and log retention settings in your environment before the first production VM moves.
When Harvester runs inside a private cloud or a provider's facility, data residency depends on the contract and the physical location of the nodes. Your team still controls the Harvester configuration, but the provider controls the building, network path and possibly the storage backing the nodes. This model adds a third party to the evidence chain, so the boundary of responsibility must be written down before workloads move.
- Data location: Confirm the country and facility of every node, including standby and backup sites.
- Backup destinations: If S3 is hosted by the provider, verify the region, encryption keys and who can read them.
- Identity and audit: Clarify whether the provider has administrative access to hypervisor hosts and how its access logs reach you.
- Shared responsibility: Document which controls belong to the provider, which to you and which to a service partner.
- Subprocessors: Ask for the list of subcontractors that touch the infrastructure.
Your evidence pack should include the signed responsibility matrix and the provider's own assurance documents, which you must obtain from the provider and its independent auditors.
What SUSE Virtualization support covers and what it does not
Harvester itself is free to download and run. It is published under the Apache License 2.0 with copyright held by SUSE, LLC, so the software carries no license fee. What you pay for is support. SUSE Virtualization is the commercially supported form of Harvester, and it is part of SUSE Rancher Prime. Before you budget, separate the software license from the support contract, because a production cluster that runs without a support entitlement still has to be patched and upgraded by your own team.
SUSE's support 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. Check which release line your target cluster will run and whether your support window covers the migration period. A cluster you plan to build in the coming months may land on a release line that is closer to end of maintenance than you expect, so ask SUSE for the current matrix in writing before you pick a version.
A Harvester support entitlement covers the components bundled with the appliance, including the host OS, Longhorn storage, the cloud provider and CSI driver, and the Terraform provider. Longhorn, however, carries an additional usage-based entitlement, and Rancher Manager or guest Kubernetes needs a separate entitlement. In practice, a quote for three hosts may not match the number you need once storage capacity and Kubernetes clusters are counted. Ask SUSE to state each entitlement, its unit of measure, how usage is measured and what happens when usage grows, and confirm all of it in the signed order.
How a move from vSphere to Harvester usually runs
The sequence moves VMs in waves onto a Harvester cluster that has been checked against its hardware minimums, with backups, storage and operator skills in place before ESXi hosts are retired. The scope, duration and effort depend on the estate and should be agreed in writing before work starts.
Inventory the estate and check hardware
The team lists every VM with its OS, disk sizes, snapshots, VMware Tools status, network port groups and storage backing, and flags any VM on vSAN-backed disks or with unusual dependencies. In parallel, each candidate host is compared against Harvester's production minimums: 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. The step is done when a signed-off inventory exists and every host either meets the minimums or has a funded purchase or replacement item.
Build and test a pilot cluster
Install Harvester on a small pilot cluster that matches the production hardware profile, then create test VMs, live migrate them between nodes, and run a backup to the chosen NFS, S3 or NAS target and restore one VM to confirm it works. Operators use this cluster to learn the Harvester dashboard, KubeVirt VM objects and Longhorn volume behavior. The step closes when a live migration and a test restore have both completed and the results are written down.
Enable the vm-import-controller add-on
An administrator enables the vm-import-controller add-on, which must be switched on before any VMware, OpenStack or OVA import can run, and creates a VMware source that points to the vCenter or ESXi endpoint with a service account that has the read permissions the import needs. Scratch storage is provisioned at about twice the size of the largest VM in the first wave, as Harvester's documentation recommends. The step is done when the source connects and lists the expected inventory.
Map networks and storage for each wave
Each vSphere port group is mapped to a Harvester VM network, including VLAN IDs, IP addressing and any multiple NIC layouts, so that migrated VMs keep their connectivity. Storage targets for the imported disks are chosen on Longhorn, and the team confirms replica settings and tiering are suited to each workload class. The step is done when a dry-run mapping document has been reviewed by the network and application owners.
Move VMs in waves with shutdown rules
VMs are imported in small waves, starting with low-risk, well-understood workloads. The controller attempts a graceful guest shutdown and forces power-off after a default of 60 seconds, so application owners agree in advance which VMs need a manual shutdown, and VMware VMs without VMware Tools need forcePowerOff or a manual stop. Each wave is validated by application owners for boot, network reachability and service checks before the next wave starts. The step closes for each wave when the owner signs off and the source VM is kept powered off but retained as a fallback.
Rebuild backup jobs to NFS or S3
Backup jobs are recreated on Harvester for every migrated VM, targeting the NFS, S3 or NAS destination chosen during design, with retention and schedule settings agreed with the data owners. The team runs a restore test for a representative sample from each workload class and records the recovery time observed. The step is done when restores from the new jobs succeed and the old vSphere backup jobs are paused on a dated plan.
Train operators on KubeVirt and Longhorn
Virtualization administrators learn the Kubernetes concepts that Harvester exposes, including namespaces, VM objects, storage classes, Longhorn volumes and the monitoring stack built on Grafana and Prometheus. Teams that also run containers agree on which platform owns which workloads and who is on call for each. The step closes when operators can complete the routine tasks in a runbook without vendor help, such as migrating a VM, expanding a volume and reading a backup report.
Decommission ESXi hosts after the last wave
Once all waves are complete and the rollback window agreed in the plan has closed, ESXi hosts are drained, removed from vCenter, and retired. Teams confirm whether any perpetual licenses or hosts still need to remain for archive or compliance reasons, since Broadcom's knowledge base states that perpetual hosts keep running after Support and Subscription expires but patches and major upgrades require an active contract. The step is done when the decommissioning record lists each host, its disposition and the final license position for finance and audit.
Common questions before switching from vSphere to Harvester
What drives the cost of moving from vSphere to Harvester?
The cost is driven by the hardware you must buy or reuse, the people who build and run the cluster, the migration work, and the support you choose. Harvester's software is Apache-2.0 licensed, so there is no per-core or per-socket license fee for the platform itself. Costs that recur include hardware refresh, staff time, and any SUSE Virtualization subscription you buy. Ask for a quote that lists each component separately: hardware, implementation, migration waves, backup integration, training and optional support. Hardware cost rises with the production minimums in the Harvester README, which call for at least 16 cores, 64 GB of memory and 10 Gbps networking per node.
How long does a migration from vSphere to Harvester take?
Duration depends on the number of VMs, their size and change rate, how many applications have hard dependencies, and how much of the estate can be shut down in each window. Live migration inside Harvester is a separate question from the migration from vSphere, which is a one-time import per VM. No timeline can be given without an inventory of the estate. Ask for a written plan that groups VMs into waves, names the cutover window for each wave, and shows the rollback step. The scope document should state the number of VMs and clusters it covers.
What does the work require from our own team?
Your team needs to supply application owners who can confirm shutdown order, network and VLAN mappings, and acceptance tests. Platform engineers need working knowledge of Kubernetes concepts, since KubeVirt, Longhorn and Harvester all run on it. Storage and network staff must confirm the 10 Gbps fabric and the disk performance the README requires. Security and compliance staff should review access roles and backup targets. Ask the partner which of these skills you must hire or train before the first wave, and which can be delivered with the work.
Can our own staff migrate vSphere VMs to Harvester without a partner?
Yes, a team with Kubernetes and Linux administration experience can enable the vm-import-controller add-on and run its own imports, provided it follows the Harvester VM import documentation. The harder parts are the operational ones: sizing hardware, designing networks, setting backup jobs, testing restores and documenting the runbooks an auditor will ask for. Work that has not been done before usually takes longer than planned. A pilot wave on non-critical VMs will show how much internal effort the full move needs.
How does Harvester handle VMs backed by vSAN disks?
Harvester's import controller reads VMs from VMware sources, but the storage underneath must be considered before import. Confirm with your VMware administrator where each disk lives, how large the scratch storage needs to be, and whether any VM uses features the import path does not support. The VM import docs recommend scratch storage of about twice the size of the largest VM being migrated. Test a representative VM from each storage tier before scheduling production waves, and confirm the exact behavior for your vSAN version with the Harvester documentation.
Does live migration in Harvester cause downtime?
The Harvester README lists live migration to another node with zero downtime as a feature. That is the vendor's stated behavior, and you should verify it on your own hardware, network and storage configuration before relying on it for critical workloads. Test live migration with the guest workloads you run, under load, and record the results. Live migration is a runtime feature and does not replace the one-time import from vSphere, which still requires shutdown and cutover for each VM.
Do we need to buy a Longhorn license to run Harvester?
Harvester itself is Apache-2.0 licensed, and Longhorn is the distributed block storage it uses. SUSE's support matrix states that a Harvester support entitlement covers the components bundled with the appliance, including Longhorn, but that Longhorn is subject to an additional usage-based entitlement. Rancher Manager or guest Kubernetes needs a separate entitlement. Ask SUSE or your reseller to confirm how these apply to your node count, storage volume and deployment before you sign. Your quote should list these entitlements as separate lines.
When is outside help worth paying for in a Harvester move?
Outside help is worth considering when the estate is large, when VMs have complex storage or network dependencies, when a regulator requires documented controls, or when internal staff lack Kubernetes experience. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and prepares evidence for compliance assessments, though independent auditors issue the assessments. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a written scope that names the VM waves, hardware validation, backup tests and handover documents.
How DeployOpen helps evaluate and migrate to Harvester
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Harvester evaluation can start from your real vSphere estate rather than a generic checklist. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory which vSphere VMs, guest operating systems and VMware Tools states are in scope for a Harvester move.
- We check candidate hosts against Harvester's production minimums for CPU, memory, disk IOPS and 10 Gbps networking before any purchase.
- We document which VMs need graceful shutdown or forced power-off, and which need a manual window, in the written scope.
How we build
- We enable and configure the vm-import-controller add-on, then map vSphere networks and sources to Harvester networks in a test cluster.
- We size scratch storage for the largest VM in each migration wave and test a pilot import from VMware before production waves.
- We configure live migration and backups to your chosen NFS or S3 targets, and test restores of representative VMs.
How we hand over
- We deliver runbooks for each migration wave, covering shutdown rules, rollback steps and post-import checks for VM networking and drivers.
- We document the Longhorn and SUSE Virtualization entitlement position so procurement and operations know what is covered and what is billed separately.
- We hand over backup and restore evidence, hardening notes and admin training for the operations team who will run the cluster.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover Harvester version upgrades, including checks against the release and support windows you confirm with SUSE.
- Security testing of the cluster, its APIs and the Kubernetes layer can be scoped separately, with findings handed to your team in writing.
