Which fits a team that already runs Kubernetes and needs VMs next to containers
If your platform team already runs Kubernetes and has a set of VMs that cannot be containerized, the question is less about hypervisors and more about where your operating skills sit. KubeVirt suits a team whose strongest people run Kubernetes, because it adds VM resource types through Custom Resource Definitions and runs controllers and agents on the cluster to schedule, launch, stop and delete VMs. It is Apache 2.0 licensed, was accepted into the CNCF in 2019 and moved to Incubating in 2022, and v1.9.1 is marked Latest on the project's GitHub releases page. vSphere suits the opposite profile: an estate that is mostly VMs, operators who run vCenter every day, and a renewal that is already priced per core. Neither choice is a superset of the other. KubeVirt does not reproduce every vSphere feature, so list the workflows your operators depend on today, then check each one against KubeVirt's documentation before you commit.
Three factors usually decide it. The first is storage. KubeVirt live migration requires that VMs using PersistentVolumeClaims use a shared ReadWriteMany access mode, and migration is not allowed with a pod network binding of the bridge interface type. Confirm that your storage backend supports ReadWriteMany for the volumes you plan to migrate, and test a live migration on your own hardware before you rely on it for maintenance windows. The second is VM count. A few dozen VMs alongside a container platform is a different operating problem from hundreds of VMs with vMotion, HA and DRS expectations, so ask how your change process and backup tooling will treat each VM. The third is in-house skill. Operating KubeVirt means operating Kubernetes control planes, etcd backups, RBAC and storage classes as well as VM lifecycle, so count those people in your plan.
A practical test is to pick two or three representative VMs, one Linux, one Windows and one with an unusual network or storage setup, and run them through the full cycle: import, live migration, backup and restore, and a node failure. Record who did each step and how long it took your team. If the results show that your Kubernetes staff can run the VMs with confidence, KubeVirt is a credible option. If the VM estate is large and the platform skills are thin, a vSphere renewal or a VM-focused platform such as Proxmox VE may be the safer path. Forklift can handle bulk moves from vSphere to KubeVirt, but its migration plans still need the same rehearsal.
Which option fits each scenario
This table matches common team profiles against vSphere, KubeVirt and related options such as Harvester and Forklift. Read each row as a conditional: the better fit depends on your existing Kubernetes footprint, storage capabilities and migration volume, and the final choice should be confirmed in a proof of concept.
| Scenario | Better fit | Why |
|---|---|---|
| Mostly containers with some legacy VMs | KubeVirt on an existing Kubernetes cluster | If the platform team already operates Kubernetes, KubeVirt lets legacy VMs sit beside pods under the same API, RBAC and GitOps tooling, though VM skills remain a separate investment. |
| Mostly VMs with a small Kubernetes footprint | vSphere or Proxmox VE, with KubeVirt considered later | When the estate is VM-first, a dedicated hypervisor cluster usually keeps operations simpler than running a Kubernetes control plane mainly to host VMs. |
| A team with no Kubernetes operators | Proxmox VE or XCP-ng | Running KubeVirt well assumes Kubernetes upgrades, etcd backups, CNI and storage operations. Teams without that skill should confirm they can staff it before choosing KubeVirt. |
| Live migration on storage without ReadWriteMany | Proxmox VE, XCP-ng or vSphere, or add shared RWX storage first | KubeVirt live migration requires shared ReadWriteMany volumes for VMs using PersistentVolumeClaims. Confirm whether your storage class offers RWX before planning migration waves. |
| Bulk moves from vSphere | Forklift for KubeVirt, or Proxmox VE import wizard as a comparison | Forklift maps sources and runs migration plans, with warm migration and changed-block tracking for VMware sources. Pilot a representative set of VMs and check scratch space, VMware Tools and guest drivers first. |
| A need for an appliance with support contracts | Harvester with SUSE Virtualization, or a commercial KubeVirt-based product | Harvester is built on KubeVirt and Longhorn and ships as an appliance, and SUSE sells support. Confirm which components the entitlement covers, since Longhorn and Rancher carry separate terms. |
What ReadWriteMany storage means for live migration
Live migration of KubeVirt VMs depends on storage and network choices made before the first VM starts. The cards below cover the access mode that PVC-backed disks need, the storage class checks that follow from it, the pod network binding that blocks migration, and the mapping of existing vSphere storage and VM network design onto Kubernetes.
Shared RWX access for PVC-backed VMs
KubeVirt live migration requires that VMs using PersistentVolumeClaims have a shared ReadWriteMany access mode, so the source and destination virt-launcher pods can attach the same disk during the move. A VM whose disks use ReadWriteOnce volumes cannot move while running. Check every disk of every VM in the first wave, including data disks added later, because one non-shared volume blocks the whole VM from migrating.
Storage class must support RWX
The access mode is only a request. The storage class and its CSI driver must actually provide shared read-write volumes with the performance the VMs need. Ask the storage vendor or the open-source project to confirm RWX support for block-mode volumes in your Kubernetes version, and test a live migration of a representative VM on that exact class before committing to it.
Bridge binding blocks migration
KubeVirt does not allow live migration when a VM uses the bridge interface type on the pod network. Teams moving VMs from vSphere often reproduce a flat port group design this way, so the VM loses its ability to move between nodes. Plan the interface binding for each network before the import, and confirm in a pilot that migration is permitted for each VM profile.
Existing vSAN and SAN estates
A vSAN datastore or SAN LUN does not map one-to-one onto a Kubernetes storage class. Snapshot behavior, replica counts, multi-attach semantics and encryption differ by product, so the migration design must name the target storage for each VM tier. Ask the storage team which current datastores hold the workloads, which of them the destination can read directly, and which need a copy during the import.
Network design for VM traffic
VM traffic on Kubernetes needs its own design: how VLANs reach the nodes, how secondary networks attach to VMs, how IP addresses move with a VM and how firewall policy applies to VM traffic. Harvester uses Longhorn for distributed block storage as an option you must confirm for your environment, and it is one of several choices. Document the storage and network dependencies for each VM group, then test failover of one node before cutover.
How KubeVirt sits on top of your Kubernetes cluster
KubeVirt does not run a second control plane beside Kubernetes. It adds VM resource types through Custom Resource Definitions, and controllers and agents running on the cluster schedule, launch, stop and delete the virtual machines. A VM is therefore an API object in the same etcd datastore, authorized by the same RBAC rules, and scheduled by the same kube-scheduler as your pods. The practical consequence is that every VM inherits the health of the Kubernetes control plane. Before you commit, confirm which Kubernetes minor version your distribution ships, check the KubeVirt release matrix for that version, and plan upgrades in the order the version skew policy requires, since kube-apiserver goes first and kubelets follow.
The shared control plane changes the operational surface in three ways. First, etcd now holds VM definitions alongside application configuration, so its backup and restore process must cover VM state too. Kubernetes expects an odd member count, recommends five members in production, and uses etcdctl snapshot save for backups and etcdutl for restores. Second, authentication is handled by Kubernetes, which does not represent users as API objects and accepts X.509 client certificates, OpenID Connect tokens or webhook authentication. Whoever can create a VirtualMachine object can start a workload that runs with hypervisor access on the node, so the RBAC roles that grant VM rights deserve the same review as cluster-admin grants. Third, Secrets are stored unencrypted in etcd by default. Cloud-init data, disk credentials and VM-level secrets are only as protected as your encryption-at-rest configuration and your least-privilege RBAC on list and watch verbs.
Data location, identity and compliance under each model
Both vSphere and KubeVirt run inside the client's own infrastructure, so residency is rarely the deciding factor. The differences sit in how users authenticate, where secrets live and who produces the evidence an assessor will ask for. Each card below names one of those decisions and what to confirm before committing.
Data residency in your own infrastructure
Both models keep VM disks, configuration and logs inside the cluster you operate. With vSphere, that means ESXi hosts, vCenter and your storage arrays. With KubeVirt, VM disks sit on PersistentVolumes provided by your storage driver, and the control plane runs on your Kubernetes nodes. Confirm where backups, Forklift migration logs and any telemetry are written, and which storage backend holds the ReadWriteMany volumes that live migration needs.
User identity and authentication
vCenter authenticates administrators through vCenter SSO, which you can tie to directory services. Kubernetes does not create user objects. It accepts X.509 client certificates, bearer tokens including OpenID Connect and JWT, webhook token authentication, or an authenticating proxy. Decide which of these your platform team will run, how group membership maps to RBAC roles that control VM access, and how offboarding revokes certificates or tokens. Confirm that the same identity source covers both the Kubernetes API and the VM console.
Secrets encryption in etcd
Kubernetes stores Secrets unencrypted in etcd by default. VM cloud-init data, registry pull credentials and database passwords often end up in Secrets, so a plain etcd default is a real exposure in regulated environments. Configure encryption at rest for the API server, restrict list and watch permissions with least-privilege RBAC, and decide whether an external store through the Secrets Store CSI Driver fits your model. Confirm how etcd snapshots used for backup are encrypted and who can read them.
Compliance evidence and audit readiness
DeployOpen can plan and implement the controls, configure logging, collect configuration evidence and prepare the documentation an assessor will request. DeployOpen does not issue audit reports, attestations or certifications, and neither does KubeVirt or the Kubernetes project. Independent auditors and certification bodies do that work. Ask your assessor which control frameworks apply, then map each VM, cluster and etcd control to an owner and a repeatable evidence source before the assessment window opens.
What a move from vSphere to KubeVirt involves
The sequence turns a set of vSphere workloads into VMs running on a Kubernetes cluster that already has the storage, networking and operations needed to keep them available, with each wave verified before the next one starts. The client's environment, including VM count, storage backend and team skills, sets how long each step takes.
Assess which VMs suit Kubernetes
Inventory every vSphere VM and sort it by dependency, licensing, storage and availability needs. Flag workloads that need PCI passthrough, vSAN-backed disks, or an unusual network setup, and note which VMs must migrate live. Your application owners and platform team sign off on the list. The step is done when each VM has a target wave and an owner, and the exceptions that stay on vSphere or move to another platform are written down.
Build or confirm the Kubernetes cluster
Confirm that the cluster follows the kubeadm high availability guidance: at least three control plane nodes, a TCP load balancer in front of kube-apiserver on port 6443, and a clear choice between a stacked etcd topology and an external etcd cluster. Plan etcd backups with etcdctl snapshot save and test a restore with etcdutl. Your platform team owns this work. It is done when a control plane node can fail in a test without losing API access and a restore has been rehearsed.
Confirm ReadWriteMany storage for live migration
KubeVirt live migration requires VMs backed by PersistentVolumeClaims to use the shared ReadWriteMany access mode, so confirm that your storage class provides it and test it under load. Check which VMs can use a bridge pod network binding, because migration is not allowed with that binding. Storage and platform engineers own this check. It is done when a test VM with an RWX volume migrates between nodes and the result is recorded.
Install KubeVirt and Forklift
Install KubeVirt, the Apache-2.0 virtual machine add-on for Kubernetes, and Forklift, the Apache-2.0 migration toolkit that maps vSphere sources to KubeVirt targets and runs migration plans. Confirm that the versions you install support your Kubernetes release, and set up access to vCenter with a read-only service account. Platform engineers do this work. It is done when KubeVirt schedules a test VM and Forklift can list the vSphere inventory.
Run a pilot with warm migration and virt-v2v
Choose a few low-risk Linux and Windows VMs and run them through a Forklift migration plan. Forklift supports warm migration with changed-block tracking for VMware sources and converts guests with virt-v2v, which installs virtio drivers. Record the downtime at cutover, any guest driver or boot issues, and how long disk copies take. The pilot is done when each test VM boots on KubeVirt, passes application checks, and the team has a written list of fixes to make before wave one.
Map networks and storage for each wave
Map each vSphere port group to a Kubernetes network attachment and each datastore to a storage class, and decide how VLANs, IP addresses and DNS records will carry over. Confirm which VMs need the same address after cutover and which need changes in load balancers or firewall rules. Network and storage engineers complete this mapping with the application owners. It is done when a written mapping exists for every VM in the next wave and the rules have been reviewed.
Validate and cut over in waves
Migrate VMs in groups by dependency, starting with stateless or non-critical services and moving to databases and core systems last. Before each wave, run the application test plan, backup restore checks and monitoring alerts on the migrated VMs. Keep a rollback path to the vSphere copy until the owner signs off. The wave is done when the owners accept the results and the rollback window has closed without use.
Run both estates in parallel
Keep the remaining vSphere hosts running until the last wave is accepted, and run backup, monitoring and patching for both estates during that period. Your operations team trains on KubeVirt, Kubernetes upgrades and VM lifecycle tasks while the old estate still serves production. The step is done when no production workload depends on vSphere, licensing or support for the old hosts has been ended as planned, and operations runbooks for the Kubernetes-hosted VMs have been tested.
Questions buyers ask before choosing KubeVirt
How much effort does a move from vSphere to KubeVirt take?
The effort depends mostly on how much of the estate is already Kubernetes-native and how many VMs must move. KubeVirt is a VM add-on for Kubernetes, so a team that already runs clusters, GitOps and storage automation adds a new workload type rather than a new platform. A team without that foundation must first build the cluster, storage, networking and monitoring layers that vCenter and ESXi provide out of the box. Ask for an inventory of VM count, operating systems, disk types, network dependencies and any vSAN or PVC-backed storage before estimating anything, because those facts decide which migration path applies.
Can our team do the switch without outside help?
A team can do it without outside help if it already operates Kubernetes in production and has people comfortable with storage classes, CNI networking, RBAC, etcd backups and cluster upgrades. Running VMs on KubeVirt also requires skills in libvirt-style VM lifecycle, virtio drivers, guest tooling and live migration behavior, which vSphere administrators may not have. The honest test is whether the same people can recover a failed node, restore etcd from a snapshot and debug a stuck migration at night. If the answer is uncertain, a fixed-scope pilot with DeployOpen can build those runbooks and hand them over in writing.
What skills does a KubeVirt platform team need?
The platform team needs skills across three layers. In the Kubernetes layer, they need control plane operations, the version skew policy, certificate and authentication configuration, and etcd operations, including backups with etcdctl snapshot save and restores with etcdutl. In the storage layer, they need ReadWriteMany-capable storage for VMs that must live migrate, because KubeVirt live migration requires shared ReadWriteMany access for PersistentVolumeClaims. In the VM layer, they need virtio driver handling, guest shutdown behavior and backup tooling. Document who owns each layer before the first wave.
How long does a KubeVirt migration take?
Duration depends on scope, not on a fixed rule. The main drivers are the number of VMs, their disk sizes, the storage backend, the network mapping, the number of application owners who must sign off, and whether the cluster must be built first. Forklift's migration plans run in waves, so a pilot of representative VMs usually comes before the bulk move. No fixed timeline applies to every estate. Ask for a written plan that lists phases, acceptance tests per wave and rollback points, and confirm the dependencies on storage and network readiness before accepting a date.
Does KubeVirt support every vSphere feature?
No, and the gap list should be settled before scoping. KubeVirt covers VM creation, lifecycle and live migration, but live migration has constraints: VMs using PersistentVolumeClaims need shared ReadWriteMany storage, and migration is not allowed with a pod network bridge interface. Features such as vSphere DRS-style placement, vSAN policies, Site Recovery Manager, NSX microsegmentation and vCenter roles must be mapped to Kubernetes equivalents or other tools. Confirm each vSphere feature your workloads depend on against the current KubeVirt user guide and your own test results, instead of assuming parity.
How does Forklift handle warm migration from VMware?
Forklift is an Apache-2.0 toolkit that maps source and destination infrastructure and runs migration plans to KubeVirt. For VMware sources it supports warm migration using changed-block tracking, so most of the disk copies while the VM keeps running and only the changed blocks move at cutover. It converts VMware guests with virt-v2v, which installs virtio drivers so the converted VM boots with KubeVirt's paravirtual devices. Test each guest operating system in a pilot wave, because conversion results and cutover downtime depend on the guest, its disks and its network configuration.
What does the Kubernetes version policy mean for upkeep?
Kubernetes maintains the three most recent minor releases, and each minor release receives about one year of patch support, roughly 14 months in total including the pre-release period. Upgrades must go one minor version at a time, with kube-apiserver first, then controller-manager, scheduler and kubelets, and kubelets may be up to three minor versions behind the API server. KubeVirt and Forklift also have their own release cycles that must match the cluster version. Budget recurring upgrade work for the cluster, KubeVirt, storage and Forklift together, and confirm the support window of the Kubernetes version you pick.
When is Harvester or SUSE Virtualization a better packaged option?
Harvester is often the better fit when a team wants a packaged hyperconverged platform on Kubernetes rather than assembling KubeVirt, storage and management itself. Harvester is Apache-2.0, built on Kubernetes, KubeVirt and Longhorn, and includes a vm-import-controller add-on for VMware sources that must be enabled first. Its production hardware minimums in the README are substantial, including 16 cores or more and 10 Gbps networking, so check those against your servers. SUSE Virtualization is the commercially supported product, and its support entitlement covers bundled components but treats Longhorn and Rancher Manager as separate entitlements. Compare both paths before choosing.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For teams weighing vSphere against KubeVirt, the work starts with a written scope that tests whether your Kubernetes estate is ready to carry virtual machines.
How we scope
- Inventory which VMs must stay on vSphere, which can move, and which need shared ReadWriteMany storage for live migration.
- Map your current Kubernetes version, control plane topology and etcd backup practice against what KubeVirt will add.
- Agree deliverables, timelines and exclusions in writing before any work starts, since most engagements are fixed-scope.
How we build
- Build a test cluster that mirrors production networking, storage classes and Forklift source connections for pilot migrations.
- Test Forklift migration plans on representative Windows and Linux VMs, including guest drivers and network mapping.
- Configure RBAC, Secrets encryption at rest and Pod Security Standards for the VM namespaces alongside existing workloads.
How we hand over
- Document the cluster design, VM templates, storage and backup runbooks, and the cutover steps for each migration wave.
- Run knowledge transfer sessions so your platform engineers can operate KubeVirt, troubleshoot live migration and handle upgrades.
- Deliver a migration log and rollback notes that your auditors or internal reviewers can read without our involvement.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan Kubernetes and KubeVirt upgrades against their published support windows and test each change in staging first.
- Prepare controls and evidence for compliance assessments; independent auditors, not DeployOpen, issue any audit reports or certifications.
