Last updated · Fusionative
Short answer
To migrate VMware VMs to KubeVirt, you inventory and group the VMs, map their networks and storage to Kubernetes equivalents, then import the disks with a tool such as Forklift (the Migration Toolkit for Virtualization) or KubeVirt's Containerized Data Importer, convert guest drivers, and cut over in waves with a rollback plan.
Why teams move VMs to KubeVirt
KubeVirt, a CNCF project, runs virtual machines as Kubernetes workloads. Teams use it to run VMs and containers on one platform and one set of operations, and many evaluate it after VMware licensing changed following Broadcom's acquisition of VMware.
Step by step
- Inventory: list VMs, operating systems, sizes, dependencies and owners; flag appliances and unsupported guests.
- Design target networking (for example Multus or bridge networks) and storage classes (for example Ceph RBD) to match each VM's needs.
- Pilot: migrate a few low-risk VMs to validate drivers, performance, backup and monitoring.
- Migrate in waves with a migration tool: cold migration for simplicity, warm migration to shorten downtime.
- Convert guests: install VirtIO drivers and the guest agent, especially for Windows.
- Cut over, validate, and keep the source VM until the rollback window closes.
Common pitfalls
- Windows guests without VirtIO drivers fail to boot after import.
- Storage performance differs from VMFS; size and test storage classes first.
- Network designs relying on VMware distributed switches need re-mapping.
- Backup, monitoring and runbooks must move with the VMs, not after.
Where FusioNative fits
FusioNative runs KubeVirt VMs with live migration, HA, snapshots, vTPM and Secure Boot on Ceph storage. Disks come in by upload, URL or registry import; Windows installs get VirtIO drivers automatically; and a VM can keep its VMware MAC address and IP. Tenancy, quotas and metering come with it.