How to migrate from VMware vSphere to Harvester without guessing at the first wave
If a vSphere renewal now means a per-core VVF or VCF subscription, or your team is uneasy about depending on one vendor's licensing, Harvester can take over your VMs, but the move is a staged project, not a single import. Harvester can import VMs from VMware through the vm-import-controller add-on, and the real work is inventory, hardware checks, network design and per-VM cutover planning. Broadcom sells vSphere only as VVF or VCF subscriptions, and perpetual hosts keep running after support lapses, yet new patches and major upgrades need an active contract, so the timeline you set should finish before that gap matters to you. This work usually falls to platform, virtualization and infrastructure teams, often with an outside implementation partner. Effort depends on estate size, guest variety (Linux, Windows, appliances and anything without VMware Tools) and how much Kubernetes experience the team already has, since Harvester is built on Kubernetes, KubeVirt for KVM virtualization and Longhorn for storage. Harvester is Apache-2.0 software maintained by SUSE, and the support model is separate from the software license, so confirm with SUSE which components your support entitlement covers before you commit.
Before the first wave, run the hardware check against the production minimums in the Harvester README: x86_64 CPUs with hardware-assisted virtualization, 16 cores or more, 64 GB of memory or more, 500 GB or more of disk per node with at least 5,000 random IOPS per SSD or NVMe disk, and 10 Gbps networking. Nested virtualization and laptops are not officially supported, so a lab test on nested hosts does not prove production behavior. Next, plan scratch storage. The VM import docs recommend scratch space of about twice the largest VM you will migrate, so size it against your biggest guest, not your average one.
For the first wave, pick a few low-risk Linux VMs with VMware Tools installed and check how the controller handles them. It attempts a graceful guest shutdown and forces power-off after a default of 60 seconds, so decide per VM whether a forced stop is acceptable, and use forcePowerOff or a manual shutdown for VMs without VMware Tools. Map each vSphere port group to a Harvester network before the import, and confirm that any VM needing live migration does not depend on a bridge-type pod network, since KubeVirt does not allow that combination.
Which vSphere capabilities map cleanly to Harvester and which need rework
This table compares common vSphere capabilities with their Harvester equivalents and marks each row as a clean mapping, a rework item or a gap to confirm. Verify every row against the Harvester version in use, because KubeVirt rules for live migration and storage affect what your existing VMs can do after the move.
| vSphere capability | Harvester equivalent | Migration note |
|---|---|---|
| VM create, edit and clone | VM creation, editing, cloning and deletion in the Harvester UI and API | Clean mapping for day-to-day VM lifecycle. Rebuild vSphere templates and content libraries as Harvester images and VM templates. |
| Live migration | Live migration to another node with zero downtime, as listed in the Harvester README | Needs rework for PVC-backed VMs. KubeVirt requires a shared ReadWriteMany access mode for PersistentVolumeClaims, so confirm your storage class supports it before the first wave. |
| Live migration with bridge pod-network interfaces | Pod network binding of the bridge interface type | Needs rework. KubeVirt does not allow migration with a pod network bridge binding, so move these VMs to a different network binding or accept a stop and start. |
| VM backups to NFS, S3 or NAS targets | Backup targets for NFS, S3 or NAS listed in the README | Clean mapping for target types. Rebuild backup schedules, retention and restore tests, since vSphere backup jobs do not carry over. |
| Distributed block storage with tiering | Longhorn distributed block storage with tiering | Replaces vSAN for general block storage, not one to one. Moving VMs off vSAN-backed disks needs the vm-import-controller path or a disk copy, and performance must be tested on your hardware. |
| Virtual IP and multiple NICs | Virtual IP and multiple NIC networking | Clean mapping for multi-NIC VMs. Rebuild port groups and VLAN mappings as Harvester networks and confirm each VM's interface order after import. |
| Rancher integration for containerized workloads | Rancher Manager integration for managing Harvester with containers | Clean for teams that already run Kubernetes. A separate Rancher entitlement applies under SUSE support, so confirm licensing before you plan the tooling. |
| vm-import-controller for VMware sources | vm-import-controller add-on, enabled first, imports from VMware, OpenStack and OVA | Clean mapping for the import path, with rework for VMs without VMware Tools. Use the forcePowerOff setting or a manual shutdown, and size scratch storage as the docs recommend. |
| DRS-style workload placement | Scheduling by Kubernetes, with no documented DRS equivalent in the sources reviewed | Gap to confirm. Test node affinity and scheduling rules on your version and rebuild any placement policy by hand. |
| vSphere HA policy tuning | Harvester node failure handling and VM restart behavior | Confirm and rebuild. Test how VMs restart after a node failure on the version in use, instead of assuming vSphere HA settings carry over. |
| vCenter roles and permissions | Kubernetes RBAC and Harvester user roles | Rebuild. Map each vCenter role to Harvester roles and test access before cutover. |
What data and integrations move, and what to rebuild by hand
Harvester's vm-import-controller moves VM disks and a basic definition, but identity, backup policy, guest tooling and automation do not come across on their own. Plan each of these as its own workstream before the first wave, and confirm the export format and source versions in the current Harvester import docs.
VM disks through vm-import-controller
The vm-import-controller add-on, enabled first, copies VM disks from vSphere into Harvester as the import path for VMware sources. Confirm in the current VM import docs which source VM types and disk formats are supported, and test one representative VM per OS family before scheduling waves. Disks on vSAN-backed storage and snapshot chains need a specific check, since they often change how long the copy takes and whether it can run cleanly.
VMware Tools and guest drivers
VMs without VMware Tools need forcePowerOff or a manual shutdown, because the controller cannot rely on a guest agent to stop them gracefully. After import, guests need KVM-compatible virtio drivers and the VMware Tools agent removed, or they may boot with degraded network or disk performance. Build a per-OS checklist covering network device names, IP reconfiguration and agent removal, and test it on a cloned VM first.
VM configuration and network mapping
Imported VMs bring their CPU, memory and disk layout, but port groups and VLANs do not map themselves to Harvester networks. Define the VLAN and cluster network mapping in Harvester before the first import, and record which vSphere distributed switch port group feeds each VM. Review multiple NIC assignments and any virtual IP addresses, since these need to be reattached by hand.
Backup jobs and retention rebuilt
vSphere backup jobs and their retention rules do not move to Harvester. Rebuild VM backups against an NFS, S3 or NAS target chosen for your data residency and restore requirements, then restore a sample VM from each target to prove the path works. Write down the retention periods your compliance owner approved, since the backup product and target settings must match them.
Roles and access rebuilt in Rancher
vCenter roles, permissions and group assignments do not transfer, so access must be rebuilt in Harvester and, where you manage containers, in Rancher or the guest Kubernetes cluster. Map each vCenter role to a documented Kubernetes role, remove standing administrator rights, and confirm identity provider integration before cutover. Ask SUSE which Rancher entitlement your access design requires, because Rancher Manager needs its own entitlement.
Monitoring and automation tied to vCenter
Scripts, monitoring checks and CMDB feeds that call the vCenter API stop working once hosts leave vSphere. Inventory every integration that reads VM state or triggers actions, then decide which ones move to Harvester's Prometheus and Grafana monitoring and which are retired. Test alerts for power state, storage capacity and backup failure against Harvester before the last vSphere cluster goes read-only.
The migration sequence from inventory to decommissioning vSphere
This sequence moves vSphere workloads to Harvester in controlled waves, so each wave proves shutdown behavior, network mapping and rollback before the next one starts, and it ends with a documented, reversible decommissioning of the old hosts.
Inventory and classify every virtual machine
Record each VM's guest operating system and version, whether VMware Tools is installed and running, its disk layout (number of disks, sizes, thin or thick provisioning, and any vSAN-backed storage), its network adapters and VLANs, and its dependencies on other systems such as databases, DNS, directory services and licensing servers. Tag each VM by business criticality and by whether it can tolerate a guest shutdown. The output is an inventory sheet that the application owners have reviewed and signed off. Ask your team to confirm which VMs lack VMware Tools, because the import controller treats them differently during shutdown.
Enable the import add-on and validate a pilot VM
Enable the vm-import-controller add-on on the Harvester cluster, then configure a VMware source with the vCenter or ESXi credentials that your security team has approved for read and migration access. Import one low-risk, non-critical pilot VM first and confirm that its disks, CPU, memory, boot mode and network adapters appear as expected, and that the guest boots and passes an application check. The output is a tested import runbook with the exact steps, settings and checks used for the pilot, which the team can repeat for every wave.
Run a parallel wave to prove the rules
Choose the first production wave from VMs that are low risk, have simple disk layouts and have a clear owner. Select VMs that let you test both shutdown paths: one with VMware Tools and one without, so you can confirm the graceful shutdown attempt and the forced power-off behavior described in the import documentation. Also verify network mapping, including VLAN tags and the routes that depend on them. Keep the source VMs powered off but intact until the owners confirm. Define rollback criteria before the wave starts, such as failed boot, lost network connectivity or a failed application check, and record the decision for each VM. The output is a wave plan with results and a go or no-go record.
Cut over production waves with shutdown rules applied
For each later wave, schedule a change window agreed with the application owners and confirm that backups of the source VMs are current. Apply the shutdown rules that the pilot validated, using forced power-off only for VMs where the owner has accepted the risk of an unclean stop. Import, boot and test each VM against its acceptance checks, then update DNS, monitoring and backup jobs to point to the Harvester copy. Record the outcome for every VM and keep the source copy for the rollback period defined in the runbook. The output is a signed cutover record for each wave that names the approver, the checks performed and any exceptions.
Decommission vSphere and keep final backups
Once every VM in scope has passed its acceptance checks and the rollback period has ended, take a final, verified backup of the remaining vSphere configuration, VM definitions and any data that the organization must retain under its records policy. Then remove the source VMs from inventory, retire the ESXi hosts from the cluster, and document the disposal or reuse of each host. Confirm with your licensing and contract owners which vSphere subscriptions to end, and check any retention obligations before deleting the last copies. The output is a retired-host list, a final backup record and a sign-off from the operations and compliance owners.
What drives the cost and duration of the move, and how to keep each one down
This table lists the main cost and effort drivers for a vSphere to Harvester move, with why each one matters and how to reduce it. Read the one-time items (import testing, runbooks, training) separately from the recurring ones (hardware, SUSE support entitlement, Longhorn usage, staff time), and use the ask-column to scope a partner quote.
| Cost or effort driver | Why it matters | How to reduce it |
|---|---|---|
| Number and type of guests | Each VM adds import, boot and validation work. Large databases, licensed applications and Windows guests usually take the most testing time. | Inventory every VM with its OS, disks, snapshots and owner. Split the estate into waves, starting with low-risk Linux guests. |
| Share of VMs without VMware Tools | The import controller attempts a graceful guest shutdown, and VMware VMs without VMware Tools need forcePowerOff or a manual shutdown. Each manual step adds coordination and an outage window. | Count these VMs before the first wave. Install or verify guest tools where the vendor allows it, and schedule manual shutdowns with application owners. |
| Graceful shutdown versus forced power-off tolerance | The default wait is 60 seconds before forced power-off. Databases and transactional services may need longer clean stops or may not tolerate forced power-off at all. | Record the acceptable shutdown behavior per application in writing. Set forcePowerOff only for guests whose owners accept it, and rehearse the stop sequence. |
| Scratch storage capacity | Harvester's VM import docs recommend scratch storage of about twice the largest VM being migrated. Undersized scratch space stalls or fails imports of large disks. | Size scratch storage from the largest VM in the wave, not the average. Confirm with the partner how it will be provisioned and reclaimed after each wave. |
| Hardware meeting Harvester production minimums | The README asks for 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. Gaps here are often the largest unplanned spend. | Audit existing hosts against these minimums before buying anything. Ask the partner to include a hardware fit review and a sizing plan in the written scope. |
| Network design and VLAN mapping | Every source port group must map to a Harvester network. Mistakes cause re-IP work, broken application dependencies and failed validation after cutover. | Document each VLAN, gateway, DHCP scope and firewall rule before the first wave. Test one mapping per wave in a non-production window. |
| Kubernetes and Rancher skills on staff | Operating Harvester means working with Kubernetes objects, KubeVirt and Longhorn. vSphere administrators may need training before they can troubleshoot independently. Rancher Manager or guest Kubernetes adds further skill needs. | Budget training for the operators who will run the cluster. Ask for knowledge transfer and runbooks as deliverables in the quote. |
| SUSE Virtualization support entitlement versus community operation | 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. Community operation shifts incident response and patch planning to your own team. A Harvester support entitlement covers bundled components, but Rancher Manager or guest Kubernetes needs a separate entitlement. | Confirm the release line and support dates for the version you plan to run. Compare a recurring SUSE subscription with the internal effort of community operation, and ask for both options in the quote. |
| Longhorn usage-based entitlement | SUSE's support matrix says Longhorn is subject to an additional usage-based entitlement beyond the Harvester support entitlement. Storage growth can therefore change recurring cost. | Ask SUSE how usage is measured. Track storage consumption per cluster from the start so the recurring cost is predictable. |
| Parallel running during the move | Source vSphere hosts, Harvester hosts and their power, cooling and rack space overlap until the last wave is validated. Perpetual vSphere hosts may still need support decisions during this period. | Plan the wave schedule so source capacity is released as early as possible. Keep rollback VMs on vSphere until each application owner signs off. |
| Testing, runbooks and cutover rehearsal (one-time) | Each wave needs functional testing, performance checks and documented rollback steps. This work is one-time per migration but scales with the number of application types. | Group VMs by application pattern and reuse test scripts across waves. Ask the partner for test evidence per wave as part of the deliverables. |
| Hardware refresh and ongoing support (recurring) | Hardware, support subscriptions, storage growth and staff time continue after cutover and repeat on their own cycles. | Model these costs for the life of the platform, not only the migration. Ask for a written split between one-time and recurring items in every quote. |
What usually goes wrong in a vSphere to Harvester move, and how to prevent it
Most failed or delayed Harvester imports trace back to a short list of causes: shutdown behavior, guest tooling, scratch space, hardware sizing, storage and network design, and unsupported test platforms. Each card names the check to run before the first migration wave begins.
Forced power-off of unclean workloads
The import controller attempts a graceful guest shutdown and forces power-off after a default of 60 seconds. Databases, message brokers and application servers that need longer to flush writes can be cut off mid-transaction. Before the first wave, list each VM that needs a longer window, set per-VM rules, and confirm that the application team has tested a clean stop and a clean start on the imported copy.
VMs without VMware Tools
Graceful shutdown depends on guest tools reporting to the hypervisor. VMware VMs without VMware Tools cannot be shut down gracefully by the controller, so they need the forcePowerOff setting or a manual shutdown before import. Inventory every VM for tools status in vCenter, decide per VM whether to install open-vm-tools first or accept a forced stop, and record that decision in the wave plan.
Scratch storage too small
The import needs scratch space while disks are converted and copied. The documentation recommends scratch storage of about twice the size of the largest VM being migrated. A wave that includes a large database server can fail late if the scratch volume is sized for the average VM. Measure the largest disk in each wave, reserve the scratch space before starting, and confirm that the volume is not shared with production workloads.
Hardware below production minimums
The 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. Reusing older hosts that fall below these figures often produces slow imports and unstable storage. Check every candidate host against the list and benchmark disk IOPS before buying or repurposing hardware.
Live migration blocked by storage or networking
Live migration needs VMs whose PersistentVolumeClaims use shared ReadWriteMany access, and it is not allowed with a bridge interface on the pod network. VMs that were imported with per-node volumes or a bridge binding will move only after a stop, which undermines zero-downtime plans. Audit the storage class and interface type of each imported VM, and change them before promising live migration to the application owners.
Running on laptops or nested virtualization
Laptops and nested virtualization are not officially supported for Harvester. A proof of concept on a nested lab can pass the import test and still behave differently under production storage and network load, which makes the results hard to rely on for a go or no-go decision. Run the pilot on bare-metal hardware that matches the production minimums, and treat any nested lab results as functional checks only.
How the move differs by starting point and estate size
A small estate with a few guests gives the team room to learn Harvester before it carries heavier production load. The main cost is skills, because Harvester combines Kubernetes, KubeVirt and Longhorn, and operators need working knowledge of all three before the first VM moves. The import path runs through the vm-import-controller add-on, which must be enabled first, so a small first wave keeps the learning curve contained.
- Sequencing: Enable the add-on, import one non-critical Linux guest, and check boot, networking and backup before moving anything else.
- Storage sizing: The Harvester documentation recommends scratch storage of about twice the largest VM being migrated, so size scratch space for the biggest guest in each wave.
- Hardware: Production nodes need x86_64 CPUs with hardware-assisted virtualization, 16 cores or more, 64 GB of memory or more, 500 GB or more of disk and 10 Gbps networking. Nested virtualization is not officially supported, so use bare metal for test hosts.
- Skills: Train the team on namespaces, storage classes, custom resources and Longhorn volumes before the cutover, not during it.
- Alternative: If the team has no Kubernetes experience and the estate is very small, a KVM platform with a simpler management model may fit better. Confirm this against your own operating model.
Before the second wave, check that the team can troubleshoot the Kubernetes layer alone, because a small team has few people to call during an incident.
A mid-size estate with Windows and Linux guests and a live migration requirement needs the most careful sequencing. Harvester supports live migration to another node with zero downtime, but KubeVirt sets conditions on storage and networking that must hold for each VM. Windows guests also need a shutdown plan, because the import controller's default behavior affects services that take time to stop.
- Live migration prerequisites: VMs that use PersistentVolumeClaims need a shared ReadWriteMany access mode, and VMs on the bridge interface type of pod network binding cannot be migrated. Audit both before promising zero-downtime moves.
- Shutdown rules: The controller attempts a graceful guest shutdown and forces power-off after a default of 60 seconds. Set the rule per VM and confirm which Windows services need longer to stop cleanly.
- Wave order: Move Linux application tiers first, then Windows servers that depend on domain services, and schedule databases in a window your team can monitor closely.
- Storage design: Size scratch space at about twice the largest VM per wave, and plan backup targets (NFS, S3 or NAS) and Longhorn tiering before the first import.
- Forklift path: Forklift offers warm migration with changed-block tracking from VMware sources and converts guests with virt-v2v, which installs virtio drivers. Compare its downtime with the built-in import on a pilot before choosing (Forklift repository).
Before committing, run one Windows and one Linux pilot through each path and record the outage each one produces.
A larger estate that already runs containers may want VMs and pods on one Kubernetes foundation. Harvester supports integration with Rancher for managing the platform alongside containerized workloads, so the design question shifts from which hypervisor to which operating model. Ownership, namespaces and support entitlements need to be settled before the first wave, not after it.
- Ownership model: A platform team typically owns the cluster, storage and upgrades, while application teams own VMs and workloads inside their namespaces. Write this split down before scheduling waves.
- Entitlements: SUSE's support matrix says a Harvester entitlement covers bundled components, but Longhorn carries a separate usage-based entitlement, and Rancher Manager or guest Kubernetes needs its own entitlement. Ask for these in writing.
- Support versions: Check the SUSE support matrix for the release line you plan to run, including maintenance and end-of-life dates, before choosing a version.
- Harvester or upstream KubeVirt: Harvester bundles the host OS, storage and management UI. Running KubeVirt on an existing cluster means the team assembles those layers itself, so weigh that effort against the appliance model.
- Bulk moves: Forklift maps source and destination infrastructure and runs migration plans into KubeVirt, which can suit a team that already operates a Kubernetes platform. Confirm which path fits the estate before committing.
Ask the vendor to confirm the entitlement list against your planned architecture, because the answer changes the cost model.
An estate with many VMs that lack VMware Tools changes the shutdown plan more than any other factor. Harvester's documentation says VMware VMs without VMware Tools need either a forced power-off setting or a manual shutdown before import. Forced power-off can interrupt databases and application writes, so the inventory and runbook work comes first.
- Inventory: Export the tools status for every VM and group guests into those with working tools, those without tools and those with unusual services or databases.
- Shutdown runbooks: For guests without tools, document the manual shutdown steps and the owner who performs them. Use forced power-off only where a crash-consistent state is acceptable.
- Database tiers: Stop application and database services in order before the shutdown, and verify backups before the import, not after it.
- Driver conversion: The Forklift path converts guests with virt-v2v, which installs virtio drivers. Test each operating system version in the estate, since conversion results vary by guest.
- Scale: Many VMs mean many scratch cycles. Size scratch to the largest guest in each wave and schedule waves so each one has a defined rollback point.
Request the tools inventory from your VMware administrators before any wave is scheduled, and keep it with the cutover runbook.
Questions buyers ask before moving vSphere VMs to Harvester
What drives the cost of moving vSphere VMs to Harvester?
The cost is driven by the work around the hardware, not by a license fee. Harvester is Apache-2.0 software, so the software itself carries no license charge, but the project still pays for hardware that meets Harvester's production minimums, for the people who design and run the cluster, for the migration waves and for testing. Recurring costs include staff time, hardware refresh, backup storage and any support entitlement you choose. A commercial support path exists through SUSE Virtualization, and the SUSE support matrix shows that a Harvester support entitlement covers the bundled components, while Longhorn carries an additional usage-based entitlement and Rancher Manager or guest Kubernetes needs a separate entitlement. Ask any partner for a written quote that lists hardware, labor by phase, backup storage, testing and each subscription line item separately.
Can our internal team migrate vSphere VMs to Harvester without outside help?
A team with strong Linux and virtualization skills can do the migration itself, but it needs Kubernetes, storage and network competence before the first wave. Harvester runs on Kubernetes, uses KubeVirt for KVM virtual machines and Longhorn for distributed block storage, so operators must understand each layer when something fails. Teams that have never run a Kubernetes cluster in production usually need training or outside help for the first cluster. A fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, backup configuration and documentation inside your own infrastructure, with scope and deliverables agreed in writing before work starts. Whichever route you choose, confirm the skills gap in a pilot before committing to a migration plan.
How long does a vSphere to Harvester project take, and what sets the timeline?
The timeline depends on the size of the estate, the number of distinct VM types and how much of the environment must be rebuilt rather than moved. No duration figure is supplied for this migration, so ask for one in writing rather than relying on a generic estimate. The main drivers are the hardware readiness check against Harvester's production minimums, the number of network mappings, the share of VMs without VMware Tools, the size of the largest disks and the scratch storage needed for conversion, the testing of application owners' acceptance criteria and the number of migration waves. Each wave needs a rollback plan and a verified backup. A team that starts with a pilot of non-critical VMs will learn more about its timeline than any estimate made on paper.
Which Kubernetes, storage and network skills does the team need for Harvester?
The team needs working knowledge of three layers: Kubernetes for cluster operation, Longhorn for block storage and network design for VM traffic. Harvester's architecture places Elemental with SUSE Linux Micro 6.2 as the host OS, Kubernetes at the core, KubeVirt for VM management and Longhorn for distributed storage with tiering, with Grafana and Prometheus for monitoring. Operators should be able to read cluster health, diagnose a node failure, manage volumes and replicas, and map VLANs and multiple NICs to VM networks. Storage and network mistakes are the most common reasons a migration stalls, so review the README's 10 Gbps networking requirement and the 5,000 random IOPS per SSD or NVMe disk minimum with your storage engineers before buying hardware. Confirm training needs with the vendor of your choice.
Can all vSphere VMs be imported into Harvester?
Most VMs can be imported, but three groups need extra planning: VMs without VMware Tools, very large disks and workloads that need scratch space during conversion. The Harvester VM import docs say the controller attempts a graceful guest shutdown and forces power-off after a default of 60 seconds. VMware VMs without VMware Tools need forcePowerOff or a manual shutdown, so decide per VM whether a forced stop is acceptable. The docs recommend scratch storage of about twice the largest VM being migrated, so size the scratch volume from your biggest disk before the first wave. Test each VM type in a pilot, check boot and drivers after conversion, and document a rollback path for databases and stateful services.
How does SUSE Virtualization support differ from community Harvester?
SUSE Virtualization is the commercially supported Harvester product, part of SUSE Rancher Prime, while community Harvester is the Apache-2.0 release you can run without a support contract. 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. A Harvester support entitlement covers the bundled components, including the host OS, Longhorn storage, the cloud provider and CSI driver and the Terraform provider. Longhorn is subject to an additional usage-based entitlement, and Rancher Manager or guest Kubernetes needs a separate entitlement. Confirm the exact release and entitlement terms with SUSE before you commit, because release status changes.
Does live migration work on Harvester after the move?
Yes, Harvester's README lists live migration to another node with zero downtime, but several conditions must hold. KubeVirt live migration requires VMs that use PersistentVolumeClaims to have a shared ReadWriteMany access mode, and migration is not allowed with a pod network binding of the bridge interface type. Check each migrated VM's storage and network binding before you rely on live migration for a production workload. Test a planned node drain in your pilot cluster, confirm that the VM stays reachable and that application sessions survive, and record the results as evidence for your change process. Where a VM cannot meet these conditions, plan a maintenance window instead.
What should we ask a partner to include in a written quote?
Ask for a quote built from a written scope, listing each deliverable and the assumptions behind it. DeployOpen works on fixed-scope engagements, and it does not publish a price list, so a quote follows from the agreed scope. Ask the partner to separate planning, hardware readiness review, Harvester and add-on setup, network and storage design, the import plan by VM group, pilot testing, cutover waves, backup and restore testing, documentation and training. Request the assumptions on VM counts, VMs without VMware Tools, largest disk size, scratch storage and number of waves, and ask what is one-time and what recurs, such as support, retainers and upgrades. Ask who performs each task and how a change in scope is priced.
How DeployOpen scopes, runs and supports 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. For a move from vSphere to Harvester, we work through the written scope first, then build and test the import path, and hand over runbooks and evidence your own team can operate.
How we scope
- Inventory the vSphere estate, including VMs without VMware Tools, snapshots and any vSAN-backed disks.
- Confirm Harvester hardware against the README minimums on each target node before any wave is planned.
- Agree in writing which VMs, networks, storage targets and backup jobs are in scope, with deliverables and timelines.
How we build
- Enable and configure the vm-import-controller add-on, then set shutdown and forced power-off rules per workload.
- Size scratch storage for the largest VM in each wave and map vSphere port groups to Harvester networks.
- Test imports on non-production copies, then run security testing on migrated workloads before cutover.
How we hand over
- Document the import procedure, shutdown exceptions, network mapping and rollback steps for each wave.
- Deliver configuration, backup and recovery runbooks so your operations team can run the cluster independently.
- Provide evidence of tested controls for your own auditors, noting that DeployOpen prepares evidence but does not issue attestations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan Harvester version upgrades and check SUSE support status and Longhorn entitlement with your vendor.
- Confirm the support model for SUSE Virtualization or community releases before choosing the production track.
