Re-platforming VMware to KVM on UPC: A Technical Migration Guide

Re-platforming VMware to KVM on UPC - Blog Banner

Most VMware workloads move to KVM with a disk conversion, a driver swap and a network remap, not a rebuild. This guide is for infrastructure architects and platform engineers planning that move onto a dedicated, single-tenant United Private Cloud (UPC). It covers how KVM differs from ESXi, how vSphere concepts map to UPC, how VMs are converted, what to watch for with Windows and vendor-certified apps, and what changes on day two.

KVM in one page, for ESXi engineers

KVM is a Linux kernel module that turns the host kernel into a type-1 hypervisor using the CPU’s hardware virtualization (Intel VT-x, AMD-V). Each VM is a regular Linux process, scheduled by the kernel like any other.

Layer	ESXi	KVM stack
Hypervisor	VMkernel (proprietary)	kvm module in the Linux kernel
Management API	vSphere API, hostd	libvirt (virsh, XML domain definitions)
Paravirtual network	VMXNET3	virtio-net, with vhost-net in the kernel
Paravirtual storage	PVSCSI	virtio-blk or virtio-scsi
Disk format	VMDK	qcow2 or raw
Firmware	BIOS or EFI	SeaBIOS or OVMF (UEFI), Secure Boot supported
Live migration	vMotion	libvirt live migration

The practical consequences:

Guests need VirtIO drivers. Modern Linux kernels include them. Windows needs the virtio-win driver package installed before or during conversion.
Performance features are standard Linux features. Huge pages, CPU pinning, NUMA placement, SR-IOV and PCI passthrough are all available for latency-sensitive workloads.
There is no per-core hypervisor license. KVM ships with the Linux kernel.

The UPC reference architecture

UPC is single tenant: one customer per platform, with business units separated logically inside it. The model has three layers.

UPC reference architecture · 3 layers, single tenant

Platform. Your organization contains business units. Each gets one or more virtual data centers (VDCs) with its own quotas, policies and catalog access.
Inside a VDC. VMs attach to vApp networks, which route through a VDC internal network to an edge gateway providing firewall, NAT, VPN and load balancing.
Resource group. VDCs draw capacity from dedicated clusters. KVM clusters carry most workloads; a VMware or Hyper-V cluster can sit alongside for apps that must stay.

How vSphere concepts map to UPC

Most runbooks translate one to one. The table lists the constructs teams ask about first.

vSphere	KVM on UPC	Notes
vCenter	UPC console and API	Self-service per organization and VDC, plus UPC-run operations
Cluster, resource pool	Dedicated cloud resource group, VDC quota	Capacity is reserved for your organization only
ESXi host	KVM host in a dedicated cluster	Managed and patched by UPC
VM template, content library	Catalog: images, templates, ISOs	Per-organization catalogs with approval by IT
vApp	vApp with its own network	Groups multi-tier apps for deploy and power operations
Port group, distributed switch	vApp and VDC internal networks (SDN)	Isolated per VDC; no VLAN tickets for new segments
NSX edge, firewall, load balancer	Edge gateway: firewall, NAT, VPN, load balancer	Configured per VDC
vMotion	Live migration between KVM hosts	Used for maintenance without guest downtime
vSphere HA	HA restart on surviving hosts	Plus active-active designs at the app layer where needed
Snapshots	Disk snapshots (qcow2 or storage-level)	Keep short-lived, as on VMware
Site Recovery Manager	UPC DRaaS	Replication to a second UPC region with tested failover
VMware Tools	QEMU guest agent plus VirtIO drivers	Installed during conversion

Migration mechanics, wave by wave

Each wave follows the same five steps, so the first wave doubles as the template for the rest.

Assess. Export the inventory from vCenter: VMs, vCPU, memory, disks, NICs, firmware type, guest OS and tools version. Map application dependencies from flow data so tightly coupled tiers move together. Flag VMs with vendor certification limits, raw device mappings, USB or GPU passthrough, or shared multi-writer disks.
Plan waves. Group VMs by dependency and risk. Start with stateless web and dev/test tiers, then app tiers, then data tiers. Set an RTO and a rollback point for every wave.
Convert. Tools such as virt-v2v read the VM from vCenter, ESXi or an exported OVA, convert VMDK disks to qcow2 or raw, remove VMware Tools, install VirtIO drivers and the QEMU guest agent, and rewrite boot configuration. Standalone disks can be converted with qemu-img convert -f vmdk -O qcow2.
Validate. Boot each converted VM in a staging VDC. Check boot, network interface names, mounts, application health, licensing checks and performance against the VMware baseline.
Cut over. Shut down the source VM, run a final sync, start it on UPC, switch DNS or the load balancer, and keep the VMware copy powered off until the wave is signed off.

Downtime per VM is typically the time to copy and convert its disks. For large or busy VMs, pre-seed the disks and run only a final incremental sync at cutover; where changed-block tracking is available, the final sync is small.

Common gotchas on Linux guests:

Interface names change (for example ens192 to ens3). Use MAC-independent configuration or update netplan, NetworkManager or ifcfg files.
initramfs must contain VirtIO modules before the first boot on KVM; virt-v2v handles this for supported distributions.
Mount by UUID or label, not by device path, since disks may appear as /dev/vda instead of /dev/sda.
Match firmware. EFI guests need OVMF; BIOS guests stay on SeaBIOS.

Windows, appliances and what stays on VMware

Not every VM should move, and the plan should say so up front.

Workload	Approach	Watch for
Linux servers	Convert with VirtIO; most move in the first waves	Interface names, initramfs, firmware type
Windows Server	Inject virtio-win storage and network drivers before or during conversion	Boot failures without the storage driver; Windows may require reactivation after the hardware change; static IPs bind to the old NIC
Databases	KMove with the app tier; consider a native replica and switchover instead of a disk copy for large, busy databases	Storage latency and IOPS against the VMware baseline
Vendor appliances, VMware-certified apps	Keep on a VMware cluster inside the same UPC platform until the vendor certifies KVM	Support statements, license keys tied to the hypervisor
Latency-sensitive or GPU workloads	CPU pinning, huge pages, NUMA alignment, SR-IOV or PCI passthrough	Live migration limits for passthrough devices

For Windows, the safest pattern is to install the virtio-win drivers and QEMU guest agent while the VM still runs on VMware, then convert. The guest then has the drivers it needs on first boot.

Networking, storage, availability and DR

Networking. Each VDC gets software-defined networks: vApp networks for app tiers, a VDC internal network, and an edge gateway with firewall, NAT, VPN and load balancing. Keep IP addresses by recreating source subnets in the VDC and cutting over at the gateway; for hybrid links, UnitedConnect® provides private connections to AWS, Azure and Google Cloud.
Storage. VM disks land on all-flash storage in your dedicated resource group. Match tiers to the VMware datastores they replace and baseline IOPS and latency during validation.
Availability. UPC targets 99.999% availability from Tier 3+ data centers. Live migration keeps VMs running through host maintenance; HA restarts VMs on surviving hosts after a failure.
Disaster recovery and ransomware. UPC DRaaS replicates to a second UPC region with tested failover. UPC Cyber Vault keeps immutable, isolated copies of critical data. Both run on the same platform, so the DR design is part of the migration plan, not a separate project.

Day two, and a pre-migration checklist

After cutover, UPC runs the platform 24/7: host patching, monitoring, backup and support. Your team keeps control of the guests and applications, self-serves new VMs from the catalog within VDC quotas, and gets real-time monitoring across compute, storage and network.

Before the first wave:

Export the full vCenter inventory, including firmware type and VMware Tools versions
Map application dependencies and group VMs into waves M
List VMs with vendor certification, RDMs, passthrough devices or multi-writer disks
Install virtio-win drivers and the QEMU guest agent on Windows VMs in advance
Check Linux guests mount by UUID or label and have VirtIO in initramfs
Record IP plans, firewall rules and load balancer configs to recreate in each VDC
Capture performance baselines (CPU ready, IOPS, latency) for comparison
Agree RTO, rollback point and sign-off owner for each wave
Confirm license portability for guest OSs and applications
Note the VMware renewal date and work back from it

Next steps

Start with a free VMware renewal assessment. UPC engineers review your inventory, flag the VMs that need special handling, size the KVM clusters and draft the first wave with you.

To learn more about our services, contact us by clicking here!