Licensing changes since Broadcom acquired VMware have pushed many infrastructure teams to ask a question they had postponed for years: where should our virtual machines live next? For organizations already running Kubernetes, one answer is to stop operating two platforms and run VMs on the cluster itself through KubeVirt. This guide covers what that move involves and how to sequence it so nothing breaks along the way.

Start with what you actually run

Export a full VM inventory before choosing any tooling: guest OS and version, vCPU and memory, disk sizes, firmware type (BIOS or UEFI), network attachments, and which application each VM belongs to. Then sort every VM into one of three groups:

  • Move as a VM: databases, licensed software, appliances and anything tied to a specific OS build.
  • Containerize later: stateless services that can move as VMs now and be rebuilt as containers once they are on the cluster.
  • Retire: forgotten test machines and duplicates. Most estates have more of these than anyone expects, and each one retired is a VM you never have to migrate.

Check the guests before you touch the disks

KubeVirt runs VMs on KVM and QEMU, so guests should use virtio devices for disk and network rather than VMware's paravirtual devices. Current Linux kernels ship virtio drivers already. Windows guests need the virtio drivers installed, ideally before the move, or they may fail to find their boot disk afterwards. Also match firmware: a VM that booted with UEFI on VMware needs UEFI on the new platform too.

Decide how the disks get across

VMware disks are VMDK files. On Kubernetes they become PersistentVolumeClaims on a CSI-backed StorageClass. There are two common routes:

  • Import tooling: the open-source Forklift project, part of the KubeVirt ecosystem, connects to vSphere, converts guests and imports their disks into PVCs, handling many VMs per run.
  • Image conversion: for a handful of VMs, export the disk, convert it with qemu-img, and upload it through KubeVirt's Containerized Data Importer.

If your storage array has a CSI driver, the imported disks can land on the same array the VMware datastores used, so the storage budget is not part of the migration.

Keep IP addresses where they matter

By default, a KubeVirt VM sits on the pod network and receives a new address. That is fine for services behind a load balancer or DNS name, but not for VMs whose IP is hard-coded in firewalls or partner configurations. Those need a bridged attachment to an existing VLAN through Multus, so they keep the address they had on VMware. Work out which VMs need which model during the inventory, not on cutover night.

Pilot, then move in waves

Pick a low-risk application for the pilot and use it to settle the things every later wave will reuse: golden images, VM sizes, RBAC roles, backup policies and the runbook for cutover. After that, migrate one application at a time with its dependencies, so a service is never split across two platforms for longer than a single change window.

Plan for day two, not just the move

The migration is a few months. Operating the VMs afterwards is years. Before the first wave, confirm how your admins will do the everyday work on the new platform: create from a standard image, snapshot before a change, migrate off a node for maintenance, reach the console, and prove who changed what. If any of those means hand-writing YAML, the team will feel the loss of the VMware console quickly.

Where AetherVirt fits

AetherVirt is the day-two layer for this plan: a console where KubeVirt VMs are created from golden images and flavors, cloned, snapshotted, live-migrated and reached through an in-browser console, with RBAC, SSO and an audit log shared with your containers. See the AetherVirt adoption path for how we sequence a rollout.