KubeVirt vs VMware vSphere: Running VMs on Kubernetes and Migration Architecture (2026)

Most enterprises that standardised on Kubernetes still run a second, parallel platform for the workloads that never became containers: databases with licence constraints, vendor appliances, Windows services and a long tail of ten-year-old line-of-business VMs. For two decades that second platform was VMware vSphere. After Broadcom moved the portfolio to subscription-only bundles, many teams reopened a question they had stopped asking: can the cluster we already operate also run the virtual machines? KubeVirt is the open-source answer, and in 2026 it is mature enough to evaluate seriously and young enough to punish careless assumptions.

KubeVirt is a Kubernetes add-on that models a virtual machine as a custom resource and runs the actual guest as a QEMU/KVM process inside an ordinary pod. That single design decision gives you declarative VMs, GitOps, Kubernetes networking and CSI storage, but it also removes the vendor-integrated stack that vSphere administrators take for granted.

What this covers: how KubeVirt works internally, a feature-by-feature mapping to vSphere, the storage, network and live-migration details that decide success, a CBT-based migration architecture using Forklift, the failure modes, and a decision checklist.

Context and Background

Hardware virtualisation on Linux is built on KVM, a kernel module that turns the CPU’s virtualisation extensions into a hypervisor, with QEMU supplying device emulation in user space. VMware ESXi is a purpose-built proprietary hypervisor with its own storage layer (VMFS and vSAN), networking (vSwitch, distributed switch and NSX) and management plane (vCenter, with DRS and HA for placement and recovery). KubeVirt reuses KVM and QEMU but replaces the proprietary management plane with Kubernetes itself.

The project was founded in January 2017 at Red Hat, joined the Cloud Native Computing Foundation (CNCF) as a sandbox project in September 2019 and was accepted as an incubating project in April 2022, according to the CNCF announcement. As of reporting in March 2026 it had not yet graduated, although maintainers were pushing for it. Red Hat remains the dominant contributor, and vendors such as NVIDIA, Intel, AMD, IBM and Microsoft also contribute, per SiliconANGLE. That matters for risk assessment: the codebase is community-governed, but much of the commercial support comes through distributions such as Red Hat OpenShift Virtualization, SUSE Harvester and similar offerings.

The release cadence is brisk. Per the KubeVirt release notes, v1.7.0 shipped on 27 November 2025, v1.8.0 on 25 March 2026 and v1.9.0 on 22 July 2026. Those notes show how fast the gap with vSphere is closing in specific areas. Version 1.7 added decentralised live migration across namespaces and clusters. Version 1.8 added incremental VM backups with a new backup API and change block tracking coverage for hotplug volumes. Version 1.9 added zstd compression of migration streams, vGPU migration and a GA persistent-reservation feature.

Why now? The commercial trigger is licensing. Broadcom converted the VMware portfolio to subscription terms from 1 February 2024, and perpetual licences can no longer be bought, per the Thomas-Krenn licence summary. vSphere is now licensed per CPU core with a 16-core-per-CPU minimum, and vCenter is no longer sold separately. In March 2025 Techzine reported, citing distributor Arrow, that the minimum per order would rise from 16 to 72 cores from 10 April, with a 20 percent surcharge for late renewals. Treat those figures as reported rather than contractual: your quote is what binds you, and terms have kept shifting since. The technical trigger is simpler: if you already run Kubernetes platform teams, running VMs on the same control plane is operationally attractive. We covered the multi-cluster side of that operating model in Kubernetes multi-cluster management with Cluster API.

The thesis of this post is that the real KubeVirt versus vSphere decision is not a feature checklist. It is a question of which team owns the integration surface. vSphere sells you a pre-integrated vertical stack. KubeVirt hands you a horizontal set of well-defined seams (CSI, CNI, the scheduler, CRDs) and expects you to choose what plugs into each one.

KubeVirt Architecture: A VM as a Pod

Direct answer: KubeVirt runs each virtual machine as a QEMU/KVM process inside a dedicated virt-launcher pod. Custom resources (VirtualMachine and VirtualMachineInstance) describe the desired VM, a cluster-wide controller schedules it, and a per-node daemon called virt-handler starts and reconciles the guest. Storage comes from PersistentVolumeClaims and networking from CNI plugins.

Figure 1: From a VirtualMachine manifest to a running guest. The scheduler places the pod, virt-handler drives the node-local lifecycle, and storage and network attach through standard Kubernetes interfaces.

Figure 1 traces the path of a single VM. A user or a GitOps controller applies a VirtualMachine manifest. The KubeVirt controller layer creates a VirtualMachineInstance (VMI) and a virt-launcher pod that requests the resources the guest needs. The standard kube-scheduler places that pod, which is the key point: there is no second scheduler, so taints, affinities, topology spread constraints and priority classes all work on VMs the way they work on containers. Once the pod lands, the node-local virt-handler daemon, a DaemonSet running alongside the kubelet, configures the guest until it matches the desired state, as described in the KubeVirt architecture documentation.

The object model: VM, VMI and friends

KubeVirt adds custom resource definitions to the Kubernetes API. A VirtualMachine is the stateful, long-lived object, roughly one-to-one with a VMI, comparable to a StatefulSet with one replica. A VirtualMachineInstance is the ephemeral running instance, usually created for you. A VirtualMachineInstanceReplicaSet manages groups of ephemeral instances, analogous to a ReplicaSet. Start and stop behaviour is controlled by spec.runStrategy, so a VM set to Always is recreated if its instance disappears.

This split matters operationally. In vSphere, a VM is one object with a power state. In KubeVirt, you edit the durable VirtualMachine, and the running instance is a derived object that can be replaced during restarts. Anyone writing automation should learn that distinction early, because changes made directly to a VMI do not survive a restart. Teams already comfortable with controllers will find the pattern familiar; our walk-through of Kubernetes operators and the reconciliation loop explains why this declarative approach recovers from partial failures without a human in the loop.

What actually runs inside the pod

The virt-launcher pod contains the QEMU process (managed through libvirt) that is the guest. The pod’s cgroup limits therefore govern the VM, which is why memory requests must cover guest RAM plus emulation overhead. The guest uses hardware acceleration through /dev/kvm, which KubeVirt exposes to pods through the device plugin mechanism, so nodes need nested or bare-metal virtualisation support. This is the first trap for cloud users: most public-cloud VM instance types do not expose KVM, so production KubeVirt on a hyperscaler generally means bare-metal instances.

Because the guest is a process in a pod, pod-level tools apply. You can see CPU and memory through the same metrics pipeline, apply NetworkPolicies, use the same service mesh sidecar patterns where supported, and let the cluster autoscaler add nodes. KubeVirt v1.7 added support for Istio 1.25 and later, per the release notes, which signals that mesh integration is an active area.

Instance types, preferences and templates

Raw VM manifests are verbose, so KubeVirt separates sizing from hardware presentation. Instance types define CPU and memory shape, while preferences define device and firmware behaviour such as disk bus and machine type. The bundled common-instancetypes set was updated to v1.7.0 in KubeVirt 1.9. If you come from vSphere, think of instance types as VM hardware profiles combined with something like a guest OS customisation specification. This lets a platform team publish a catalogue (small, medium, memory-optimised) and keeps tenant manifests short.

A minimal VirtualMachine looks like this:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: app-db-01
spec:
  runStrategy: Always
  instancetype:
    name: u1.large
  preference:
    name: rhel.9
  dataVolumeTemplates:
    - metadata:
        name: app-db-01-root
      spec:
        source:
          http:
            url: https://images.example.internal/rhel9.qcow2
        storage:
          accessModes: [ReadWriteMany]
          volumeMode: Block
          resources:
            requests:
              storage: 100Gi
  template:
    spec:
      domain:
        devices: {}
      volumes:
        - name: rootdisk
          dataVolume:
            name: app-db-01-root

The ReadWriteMany access mode with Block volume mode is deliberate. It is the combination that makes live migration possible on most storage back ends, which we return to below. The image URL and instance type names here are illustrative placeholders, so check the names available in your cluster with kubectl get virtualmachineclusterinstancetype.

Feature Mapping: KubeVirt Versus vSphere

Direct answer: Almost every vSphere capability has a Kubernetes-native counterpart in KubeVirt, but the counterpart is usually a separate component you operate yourself: CSI replaces VMFS and vSAN, CNI and Multus replace vSwitches and NSX, the scheduler and eviction-driven live migration replace DRS and HA, and CDI replaces content libraries and OVF import.

Figure 2: How the vSphere management stack maps onto Kubernetes interfaces. The dotted lines show the conceptual equivalents rather than one-to-one feature parity.

Figure 2 is the mental model to carry into a proof of concept. The left column is a vertically integrated product from one vendor. The right column is a set of open interfaces where each box can be filled with different software. That is the core trade: flexibility and no single-vendor dependency in exchange for integration work.

Compute and placement

vCenter’s Distributed Resource Scheduler (DRS) balances VMs across hosts using load metrics and moves them with vMotion. In Kubernetes, the scheduler places VMs at creation using requests and constraints, and the default scheduler does not rebalance a running pod. To approximate DRS you add a descheduler or a custom policy that evicts pods, and for VMs the eviction triggers a live migration if the VM is configured with an evictionStrategy of LiveMigrate. The release notes show active work here: v1.8 added migration priority so that important migrations are processed first, and v1.9 added stall detection that can fall back to post-copy or stop-and-copy.

High availability (HA) behaves differently as well. vSphere HA restarts VMs on surviving hosts when a host fails, using datastore heartbeating. Kubernetes marks a node NotReady, and after the eviction timeout the pod controller recreates the workload elsewhere. For a VM with runStrategy: Always this works, but the guest suffers a hard power-off, just as in vSphere HA, and recovery time depends on node failure detection settings. Fast recovery of stateful VMs needs fencing, because a partitioned node could still be writing to a shared volume. The Kubernetes ecosystem handles this with node health-check and remediation operators, which are extra components to install and test. Do not assume “Kubernetes restarts things” is equivalent to a tested HA design.

Storage

On vSphere, VMs live on datastores: VMFS on shared block storage, NFS, or vSAN. VMDK files are the unit. On KubeVirt, every disk is a PersistentVolumeClaim served by a CSI driver. The Containerized Data Importer (CDI) populates those claims from HTTP images, registries or existing PVCs through a DataVolume abstraction, and handles uploads and clones.

The consequences are significant. Your storage back end defines your capabilities. Ceph RBD via Rook, an enterprise SAN with a CSI driver, or a software-defined layer such as Longhorn each behave differently for block-mode RWX, snapshots and clones. A weak CSI driver produces a weak VM platform, however good KubeVirt itself is. During evaluation, test the exact driver you will run in production for: RWX block volumes, volume snapshots, clone speed, expansion and behaviour during node failure. KubeVirt v1.9 moved the ExpandDisk feature to GA, which helps with online growth, but the underlying driver must still support expansion.

Networking

vSphere networking ranges from standard switches to distributed switches and NSX with overlay segments and a distributed firewall. KubeVirt VMs attach to the pod network by default, in which case the guest sits behind masquerade NAT presented by the pod interface. For anything that needs a routable IP, VLAN trunking or an L2 segment shared with legacy hosts, you add secondary interfaces through Multus and a NetworkAttachmentDefinition. Options include Linux bridges, macvlan-like patterns, SR-IOV for near-wire-speed throughput, and OVN-Kubernetes secondary networks for overlay segments with their own IPAM.

Be aware of recent changes. KubeVirt v1.8 removed the macvtap core binding and SLIRP, so older tutorials that rely on them are out of date. The passt binding, which supports seamless migration with preserved TCP connections, reached beta in v1.8 per the release notes, after an alpha in v1.7. If your VMs depend on long-lived TCP sessions surviving migration, test this specifically rather than assuming parity with vMotion.

Management, tooling and the ecosystem

vCenter gives a single UI, role-based access control, templates, tagging, events and an established API. In KubeVirt, the API is Kubernetes, authorisation is Kubernetes RBAC, and the UI depends on your distribution (the OpenShift console, Harvester’s UI, or a community dashboard). Backup is a good illustration of ecosystem dependency: vSphere has VADP-based backup products from nearly every vendor, while Kubernetes backup vendors have added KubeVirt support at varying depths. KubeVirt’s own incremental backup API appeared in v1.8, so expect the ecosystem to keep catching up through 2026.

Day-two operations tooling also differs. Ansible, Terraform and Crossplane providers exist for Kubernetes resources, so a VM becomes another YAML object in the same pipeline as your services. That is a real productivity win for teams that already operate this way, and a learning curve for classic virtualisation administrators.

Decision Matrix and Cost Mechanics

Direct answer: Choose KubeVirt when you already run production Kubernetes with a competent platform team, have storage and networking that support RWX block and secondary networks, and your VM estate is mostly Linux and mainstream Windows. Keep vSphere for estates dependent on vendor-certified stacks, advanced features without a counterpart, or where team skills are the binding constraint.

Dimension	KubeVirt (on Kubernetes)	VMware vSphere
Control plane	Kubernetes API, CRDs, RBAC	vCenter
Hypervisor	KVM and QEMU, Linux kernel	ESXi, proprietary
Licensing	Open source (Apache 2.0 for KubeVirt); distributions sell support	Per-core subscription bundles
Live migration	Yes, needs RWX storage or storage migration; cross-cluster since v1.7	vMotion, mature, Storage vMotion included in Standard
Resource balancing	Descheduler plus eviction policy	DRS built in
Restart on failure	Controller recreates VM after node loss	vSphere HA built in
Storage	Any CSI driver, CDI for imports	VMFS, NFS, vSAN
Networking	CNI plus Multus, OVN, SR-IOV	vSwitch, vDS, NSX
GPU and devices	Passthrough, vGPU, DRA support evolving	Mature vGPU and passthrough
Backup ecosystem	Growing, varies by vendor	Very broad
Skills required	Kubernetes, Linux, storage	vSphere administration
Vendor risk	Distribution dependent	Single vendor

The Apache 2.0 licence statement reflects the project’s repository licence as I understand it; confirm it against the distribution you choose. Support terms vary by vendor.

A cost model you can reproduce

Avoid trusting anyone’s published “savings percentage”. Instead, build your own model from inputs you can verify. The following arithmetic is illustrative only, using made-up prices to show the structure.

Suppose a cluster has 8 hosts, each with 2 CPUs of 32 cores. That is 512 physical cores. Under a per-core subscription model, the licensed cores are 512 multiplied by the per-core annual price in your quote. Call the price P. The VMware line item is then 512 × P per year, before any bundle-specific add-ons. For KubeVirt, the line items change shape: a distribution subscription (often priced per core or per node, if you buy one), plus platform engineering time, plus storage software if you replace vSAN, plus migration project cost spread over the planning horizon.

The honest comparison has a break-even that depends on the migration labour. A one-time migration of, say, 600 VMs consumes engineer-months for inventory, testing, runbooks and cutover coordination. Those costs are real and front-loaded, while licence savings accumulate across years. So the correct question is the payback period, not the percentage reduction. Also factor in whether your hardware is under-utilised: licensing is per physical core, so consolidating VMs with better packing reduces licensed cores on either platform. Run the model with three scenarios (migrate everything, migrate the easy 60 percent, migrate nothing and renegotiate) and compare.

For AI-heavy estates the calculation has an extra dimension. Platforms that run GPU training jobs and VMs on the same Kubernetes substrate can share capacity, and the scheduling story is covered in our Slurm versus Kubernetes comparison for AI training. KubeVirt v1.7 added DRA support for GPUs and host devices, and v1.9 added vGPU migration, so converged scheduling is becoming practical, though still an area to test carefully.

Live Migration, Storage and Network Details That Decide Success

Direct answer: KubeVirt live migration moves a running guest between nodes by starting a target virt-launcher pod and streaming memory over the network while the source keeps running. It requires shared storage (usually RWX block), compatible CPU models between nodes, and enough network bandwidth to converge faster than the guest dirties memory.

How a live migration proceeds

A VirtualMachineInstanceMigration object requests a migration, typically created by virtctl migrate, by a node drain, or by the eviction path. KubeVirt starts a target pod on a different node, and the two QEMU processes negotiate a memory transfer. Pre-copy iteratively sends memory pages, re-sending any that the guest has modified, until the remaining dirty set is small enough to stop the guest briefly and transfer the rest. If the workload dirties memory faster than the network can drain it, pre-copy never converges. That is a property of the workload and link, not a bug.

KubeVirt offers several levers. MigrationPolicy resources can set bandwidth limits, completion timeouts, and whether post-copy is allowed. Post-copy moves execution to the target early and fetches remaining pages on demand, which guarantees completion but risks guest failure if the network breaks mid-migration. KubeVirt v1.9 adds stall detection that can switch to post-copy or stop-and-copy, multifd compatible with post-copy, and zstd compression, per the release notes. Compression trades CPU for bandwidth, so measure on your own hardware rather than assuming a gain; I am not aware of a public benchmark that generalises across workloads.

Decentralised live migration, introduced in v1.7, extends this across namespaces and clusters. That opens a path for cluster upgrades by building a new cluster and moving VMs, but check the maturity of the specific feature gates in your version.

Storage requirements for migration

For a standard live migration both nodes must reach the same disk concurrently. In practice that means a ReadWriteMany PVC, and for block devices a driver whose RWX block support is actually safe for concurrent access during the migration window. Ceph RBD supports this pattern in block mode and SAN-backed CSI drivers can too. NFS-backed filesystem volumes are possible but typically perform worse for database-style VM I/O.

If your storage cannot provide RWX, you are limited to offline moves and storage-assisted copies, which sharply reduces the operational benefit. This is the most common reason pilots stall: the team validates virtualisation features but only later discovers that their default StorageClass is RWO-only. Put RWX block as a gating test in week one.

Node and CPU compatibility

Live migration needs the target to expose a compatible CPU feature set. KubeVirt can use a host-model or a named CPU model, and mixed-generation clusters are best served by a baseline model so guests can move freely. Using host-passthrough gives maximum performance and the least portability, and the v1.8 notes mention that cross-vendor migrations are blocked, so Intel-to-AMD moves are not expected to work. A practical policy is to define node pools by CPU family, label them, and keep a VM’s migration domain inside a pool.

Networking during migration

With default pod networking, the guest’s IP is tied to the pod, so an in-place migration changes the pod identity beneath it. This is why the passt work on seamless migration matters: it aims to preserve established TCP connections. With Multus secondary interfaces on a bridge or VLAN, the guest keeps its L2 identity as long as both nodes attach to the same segment. Verify that gratuitous ARP or equivalent announcements reach upstream switches after cutover. Add synthetic traffic tests to your migration validation, such as a continuous ping and a long-lived TCP stream, and record the observed gap.

Observability

KubeVirt exports Prometheus metrics for VMs and for migration progress, and standard node metrics cover the hosts. Because virt-launcher is a pod, logs for the libvirt and QEMU layers are accessible via kubectl logs. Alert on migration failures, VMs stuck in Scheduling, and CDI imports taking longer than expected. The v1.8 release notes mention that decentralised live migration now reports its own condition on VMI and migration objects, which makes alerting cleaner.

Migration Architecture: vSphere to KubeVirt

Direct answer: The common path uses Forklift (packaged by Red Hat as the Migration Toolkit for Virtualization) to read VM inventory from vCenter, copy disks into PVCs with CDI, convert the guest for KVM, and create a KubeVirt VirtualMachine. Warm migration uses VMware changed block tracking to keep downtime to the final delta and cutover.

Figure 3: Warm migration sequence. A base copy is made while the source VM runs, CBT snapshots copy only changed blocks on a schedule, and cutover shuts the source down for a final delta.

Cold versus warm migration

Per Red Hat’s documentation on cold and warm migration, cold migration is the default. The source VM is shut down while data is copied, each block is copied once, and the guest is converted before transfer. Downtime is therefore the whole copy time.

Warm migration keeps the source running. In the precopy phase, most of the data is copied while the VM runs, and disk changes are captured with CBT snapshots taken every hour by default (the interval can be changed on the forklift-controller deployment). At cutover, the VM is shut down, the remaining data is migrated, and the guest is converted. RAM contents are not migrated. This distinction is important: warm migration is not live migration. You still get a reboot on the target and a brief outage, typically shorter than copying everything, but it is not zero-downtime.

The documented requirements are specific. CBT must be enabled on each source VM and each of its disks. A VM supports up to 28 CBT snapshots, and if too many accumulate and the controller cannot create a new one, the migration can fail. Warm migration is supported from vSphere and RHV sources. The documentation also gives a sizing rule: cold migration is more time-efficient for a VM with one large disk, while warm migration is more time-efficient when a large amount of data is spread evenly across several disks. Disks in a cold migration are transferred one at a time per VM.

What conversion does to the guest

Disk copying is only half of the problem. VMware guests use paravirtual devices (vmxnet3, pvscsi) and carry VMware Tools. A KVM guest wants virtio drivers and the QEMU guest agent. Forklift uses libguestfs-based conversion tooling (the virt-v2v family) to adapt the guest, injecting virtio drivers for Windows and adjusting boot configuration for Linux. If conversion fails, the cold migration fails immediately, per the docs. The documentation also warns that if no package manager is available during migration, the toolkit may not install qemu-guest-agent, so it must be installable at first boot or installed manually.

Treat conversion as the highest-risk step for older operating systems, unusual boot loaders, encrypted disks and guests with heavy driver customisation. A pilot of ten representative VMs reveals more than reading compatibility lists.

Network and storage mapping

Forklift uses mapping objects to connect source and target. A NetworkMap ties vSphere port groups to NetworkAttachmentDefinitions or the pod network. A StorageMap ties datastores to StorageClasses. Mapping errors cause the most predictable failures: a VM lands on the pod network with a new IP because its port group was not mapped, or on a slow StorageClass because a datastore was mapped carelessly.

An abbreviated Plan resource shows the shape of the declaration. Field names should be confirmed against the Forklift version in your cluster, since the API evolves:

apiVersion: forklift.konveyor.io/v1beta1
kind: Plan
metadata:
  name: wave1-finance
  namespace: openshift-mtv
spec:
  warm: true
  provider:
    source:
      name: vcenter-prod
      namespace: openshift-mtv
    destination:
      name: host
      namespace: openshift-mtv
  map:
    network:
      name: wave1-netmap
      namespace: openshift-mtv
    storage:
      name: wave1-storagemap
      namespace: openshift-mtv
  targetNamespace: finance-vms
  vms:
    - name: app-db-01
    - name: app-web-01

Data path and throughput

Disk data moves from the ESXi hosts through the Forklift importer pods into PVCs. Throughput depends on the vSphere data path (network versus VDDK transport), network bandwidth between the VMware environment and the cluster, and the target storage’s write rate. I will not quote a single copy rate because it varies by an order of magnitude between environments. Measure with a representative VM, compute GB per hour, and extrapolate to your data volume to plan waves. A simple formula: wave duration is roughly total changed data divided by sustained transfer rate, plus the cutover window, plus validation time.

Alternatives to Forklift

You are not forced to use one tool. Some teams export disks and import them with CDI or virtctl image-upload, which is acceptable for a handful of VMs and gives full control but no automation. Others re-platform into containers where feasible, which is the genuinely cloud-native result but a different project scope. Some storage vendors offer array-assisted migration paths. Pick based on estate size: scripts for tens of VMs, Forklift for hundreds, and a re-platforming programme for the applications worth modernising.

Runbook and Wave Planning

Figure 4: A wave-planning decision flow. Unsupported guests stay put or are re-platformed; the rest are routed by downtime tolerance.

Figure 4 turns the technical choices into a triage process. Start by inventorying every VM from vCenter: operating system and version, disk layout, attached devices, snapshots, network port groups, and dependencies on VMware-specific features such as fault tolerance, raw device mappings, vSAN storage policies or NSX distributed firewall rules. Each of those has to be mapped, re-implemented or accepted as a loss.

Next, classify by guest support and downtime tolerance. Mainstream Linux and recent Windows Server guests are the easy tier. Appliances sold as OVA images with vendor support contracts are different: the vendor may not support KubeVirt as a hypervisor, so migrating can void support. That risk is contractual rather than technical, and is invisible in a lab. Ask vendors in writing.

Suggested wave structure

Wave 0, the pilot. Ten to twenty low-risk VMs including at least one Windows guest, one multi-disk database and one VM with a static IP on a VLAN. The goal is to find process flaws, not to hit a number.
Wave 1 to 3, the bulk. Group by application so dependent VMs move together, and schedule cutovers in business windows. Use warm migration for large data volumes to keep the cutover short.
The tail. Appliances, legacy operating systems and anything with unsupported hardware. Decide per item: keep on a shrunken VMware footprint, re-platform, or retire. A reduced VMware estate still triggers licensing minimums, so check what the smallest footprint costs before you promise an exit date.

Validation per VM

After each cutover, check the following: boot success and guest agent reporting, IP and DNS, application health checks, disk performance compared to a pre-migration baseline you captured, backup job running against the new platform, monitoring agent reporting, and time synchronisation. Keep the powered-off source VM for a defined rollback window. The rollback is simple during that window (power the source back on and revert DNS), but only if no data was written to the new copy that the old one lacks. Define a data-divergence policy before cutover, not during an incident.

Trade-offs, Gotchas, and What Goes Wrong

KubeVirt shifts complexity rather than removing it. The most frequent failures are not exotic.

Storage assumptions. RWO-only default StorageClasses block live migration. A CSI driver with weak snapshot or clone behaviour makes backups and templating slow. Teams that replace vSAN with a distributed storage layer on the same nodes need to size for rebuild traffic competing with VM I/O during failures.

Noisy neighbours and CPU management. vSphere has long-established CPU and memory reservations, shares and NUMA handling. In Kubernetes, guaranteed QoS pods, the CPU manager and dedicated CPU placement are the equivalent tools, and KubeVirt v1.8 added a kubevirt.io/cpumanager node label so dedicated-CPU VMs find suitable nodes. These features need to be configured deliberately. Memory overcommit is also a trap: the guest’s RAM is a pod memory request, and a node under pressure can evict or OOM-kill a launcher pod, which a guest experiences as a power loss.

Hard power-off on failure. Both platforms restart VMs after host failure without graceful shutdown. Databases need crash-consistent storage and tested recovery. The Kubernetes version adds the fencing question described earlier.

Upgrade coupling. A Kubernetes upgrade drains nodes, which migrates VMs. Large, memory-heavy or write-intensive guests may not converge, which blocks the drain. Plan upgrades with migration policies, maintenance windows and, for stubborn VMs, a deliberate shutdown procedure. Versions of KubeVirt also have their own supported Kubernetes ranges, so upgrades must be sequenced.

Feature gaps and maturity. Features such as cross-architecture virtualisation and DRA-based SR-IOV networking were alpha in v1.9, and other items such as HotplugVolumes moved to beta only in that release, per the notes. Do not build a production dependency on an alpha gate. Equally, features you rely on in vSphere such as Fault Tolerance, VM-level encryption integrations or specific third-party appliance certifications may have no equivalent.

Security model. Isolation is a hardware-virtualised boundary, which is stronger than container isolation, but the virt-launcher runs with privileges that need care. Use Pod Security settings appropriate to the namespace, restrict who can create VirtualMachine objects, and apply the seccomp profile gate, which reached beta in v1.8. Confidential computing support (AMD SEV, Intel TDX) is progressing, with IBM Secure Execution reaching GA in v1.9 per the notes.

Skills and on-call. The biggest risk is organisational. A classic virtualisation team and a Kubernetes team have different mental models, and the on-call engineer who understands QEMU, CSI and CNI simultaneously is rare. Budget for training and for a joint operating model.

Anti-pattern: lift and shift into the pod network. Migrating VMs with static IPs onto masquerade NAT breaks applications that embed addresses or use inbound protocols. Map to secondary networks first, and only then consider re-addressing.

Practical Recommendations

Treat the decision as a staged evaluation rather than a platform swap. Begin with the constraint that is hardest to change: storage. Prove that your chosen CSI driver delivers RWX block volumes, snapshots, clones and acceptable latency under failure. Then prove networking for the VLANs and routing your VMs need. Only after that does the hypervisor layer matter, because KubeVirt’s KVM base is well understood.

Pick a distribution deliberately. If you want vendor support, evaluate commercial distributions on SLA, supported guest list, upgrade policy and backup integration. If you self-support upstream KubeVirt, accept that you are building a platform product and staff accordingly. Pin to a release, track the notes for each upgrade, and keep a test cluster that mirrors production.

Run a pilot with real data and measure what matters to you: migration downtime per VM, post-migration I/O compared to baseline, time to recover from a node failure, and effort per VM in engineer hours. Use those measured numbers in the cost model instead of vendor claims. Negotiate VMware renewals in parallel; a credible migration plan changes the conversation even if you stay.

Pre-commitment checklist:

[ ] RWX block storage proven with the production CSI driver, including live migration under load
[ ] Secondary networks tested for VLAN, MTU and post-migration ARP behaviour
[ ] Guest inventory classified: supported, needs work, vendor-restricted
[ ] Vendor support statements obtained in writing for appliances
[ ] Backup and restore tested end to end on the new platform
[ ] Node failure and fencing behaviour tested with a stateful VM
[ ] Upgrade drain tested with the largest, busiest guests
[ ] Cost model built from your own quote and measured effort, with a payback period
[ ] Rollback and data-divergence policy defined for each wave
[ ] On-call training plan covering KVM, CSI and CNI failure modes

Frequently Asked Questions

Is KubeVirt a replacement for VMware vSphere?

For many general-purpose Linux and Windows workloads, yes, provided you have the storage, network and skills to run it. It is not a drop-in clone: vCenter, DRS, HA, vSAN and NSX map to several separate Kubernetes components rather than one product. Estates with certified appliances or features such as Fault Tolerance should evaluate gaps first. A hybrid outcome, with a smaller VMware footprint kept for the tail, is common and often sensible.

Does KubeVirt support live migration like vMotion?

Yes. KubeVirt performs live migration by starting a target pod and streaming guest memory while the source keeps running, and it supports pre-copy, post-copy and, in recent releases, stall detection and compression. It typically needs ReadWriteMany storage and compatible CPUs. Cross-namespace and cross-cluster decentralised migration arrived in v1.7. Convergence depends on how fast the guest dirties memory, so test with your busiest workloads.

Can I run KubeVirt on a public cloud?

Only where nodes expose hardware virtualisation. Most standard cloud instance types do not, so production deployments usually use bare-metal instances, and nested virtualisation is slower and unsupported in many setups. Check your provider’s documentation for the instance families that expose KVM. For on-premises clusters, any host with virtualisation extensions enabled in firmware works.

How do I migrate VMs from vSphere to Kubernetes?

Use Forklift (Red Hat’s Migration Toolkit for Virtualization) or a similar tool. It reads inventory from vCenter, copies disks to PVCs using CDI, converts guest drivers for KVM, and creates VirtualMachine objects. Warm migration uses VMware changed block tracking to keep the source running until cutover, then performs a short outage. You define network and storage maps, then run waves, validating each VM afterwards.

Is KubeVirt production-ready in 2026?

It is in production at many organisations through commercial distributions, and the release notes show steady maturation, but it remains a CNCF incubating project rather than a graduated one as of March 2026 reporting. Readiness depends on your use case. Core compute, storage and migration are well exercised; newer features marked alpha or beta should be treated accordingly. Run a pilot against your workload mix before deciding.

What does VMware licensing look like after the Broadcom changes?

Broadcom sells subscription bundles priced per core, with a 16-core-per-CPU minimum and no new perpetual licences, per the Thomas-Krenn summary. In March 2025, Techzine reported a planned increase of the per-order minimum from 16 to 72 cores, citing a distributor. Terms continue to change and differ by contract, so rely on your own quote and verify current rules with Broadcom or an authorised reseller.