VMware to CloudStack Migration: What Breaks and How to Plan for It

Why these migrations fail at boot, not during copy

Copying a virtual disk from a VMware datastore to CloudStack primary storage is a solved problem. What is not solved by a copy is everything the guest operating system silently assumed about the platform underneath it: which storage controller presents its boot disk, which network device its IP configuration is bound to, which guest tooling reports its health, and which MAC address its software licences and DHCP reservations were keyed to. Change the hypervisor and every one of those assumptions breaks at the same moment — first boot.

That is why migration plans built around "copy the data, then fix whatever comes up" run long. The fixes land in the cutover window, under pressure, on the systems that matter most. The challenges below are the complete list of what actually goes wrong; plan them in this order and first boot becomes a non-event.

Challenge 1: Guest OS conversion — VMware drivers out, virtio in

VMware guests run on VMware paravirtual hardware: PVSCSI or LSI storage controllers, VMXNET3 network adapters. KVM — the hypervisor under CloudStack — presents virtio devices instead. The guest must have virtio drivers available before it boots on the new platform, because the boot disk itself is behind the new controller.

Windows: the boot-critical driver problem

Windows loads boot-critical storage drivers from a list it builds at install time. A Windows guest that has only ever seen VMware storage controllers has no virtio-blk or virtio-scsi driver staged, so its first boot on KVM stops with the infamous 0x0000007B INACCESSIBLE_BOOT_DEVICE error. The fix is mechanical — inject the virtio driver package into the offline image and register it as boot-critical — but it must happen during conversion, not after the failed boot. Network drivers are more forgiving (Windows will boot without them) but a Windows server that boots with no NIC is not meaningfully migrated.

Linux: initramfs rebuilds and the interface rename

Most modern Linux distributions ship virtio modules, but whether they are in the initramfs — the early-boot filesystem that has to mount the root disk — depends on what hardware was present when that initramfs was generated. A guest built on VMware may need its initramfs rebuilt with virtio included, or it drops to an emergency shell looking for a root device that no longer exists.

The subtler failure is networking. Predictable interface naming derives names from the underlying hardware: a VMXNET3 adapter enumerates as something like ens160; the virtio replacement appears as ens3 or enp1s0. Every piece of network configuration keyed to the old name — netplan files, NetworkManager profiles, ifupdown stanzas, firewall rules — silently stops matching. The guest boots cleanly, the kernel is happy, and the machine is unreachable.

What virt-v2v automates — and what it doesn't

The open-source conversion tool virt-v2v handles much of the mechanical work: driver injection, initramfs regeneration, VMware Tools removal, bootloader adjustments. What no converter can do from outside the disk is decide your network identity policy — which IPs must survive, which interfaces map to which CloudStack networks — or prove that the converted application actually works. Conversion is necessary; it is not sufficient.

Challenge 2: Network identity doesn't survive the move

MAC addresses can't follow you

VMware assigns MACs from its own registered OUI ranges (the 00:50:56 prefix family). CloudStack/KVM assigns from different ranges, and importing a VMware-prefixed MAC is somewhere between unsupported and operationally unwise. Anything keyed to the MAC breaks: DHCP reservations, licence activations bound to the NIC, switch port security, monitoring inventory. Treat the MAC as lost at migration time and enumerate what depended on it before you move.

Static IPs and the applications pinned to them

The IP configuration usually lives inside the guest, bound to an interface that just changed name (Linux) or identity (Windows, which treats the new NIC as brand-new hardware and reverts it to DHCP). If the address must survive — domain controllers, database listeners, anything in other systems' connection strings — capture the live network identity before power-off and re-apply it on the destination as part of the migration, not as a help-desk ticket afterwards.

Mapping port groups to CloudStack networks

VMware port groups and distributed switches do not translate one-to-one into CloudStack's network model of zones, VLANs, isolated networks and VPCs. Build the mapping table early — source port group, VLAN, destination CloudStack network, who owns the firewall rules — because every VM you migrate consumes it.

Challenge 3: Storage format conversion (VMDK → QCOW2)

The disk format conversion itself — VMDK to QCOW2 — is well-trodden. What surprises teams is the state that does not transfer: VMware snapshots must be collapsed before conversion, thin/thick provisioning semantics differ, and VMware's changed block tracking state is meaningless on the other side. Any incremental relationship your tooling had with the source disk ends at the format boundary.

On the CloudStack side, primary storage choice shapes everything downstream: QCOW2 on NFS, ZFS-backed volumes, or Linstor/DRBD replicated storage all behave differently for snapshots and backup. How you will back these workloads up on day one is a decision to make before the first VM lands, not after.

Challenge 4: Operational tooling — VMware Tools out, qemu-guest-agent in

VMware Tools serves no purpose on KVM and known harm if left installed — leftover services, phantom devices, boot delays. Its CloudStack counterpart, qemu-guest-agent, is what gives the platform clean shutdowns, IP reporting and filesystem quiesce for consistent snapshots. Removal of one and installation of the other belongs in the conversion step.

• Windows offline-disk surprise: Windows' SAN policy can leave non-boot data disks offline after the move because they look like "new" disks. Two lines of diskpart fix it — if it is in the runbook.
• CD-ROM leftovers: mounted ISO images and stale optical devices block some operations and confuse boot order. Strip them at conversion.
• Monitoring and agents: anything that discovered the VM via vCenter needs re-pointing; in-guest agents keyed to hardware IDs may need re-registration.

Challenge 5: Your backup history doesn't come with you

This is the challenge nobody puts on the project plan. Years of restore points sit in your backup platform in a VMware-only format, restorable only into the environment you are decommissioning. Retention obligations do not reset because you migrated: if policy says seven years of recovery capability, you either keep a zombie vSphere cluster alive purely as a restore target, pay to convert history wholesale, or accept a compliance gap.

The alternative is to treat backup lineage portability as a migration requirement: recovery points stored in a platform-neutral format, restorable to either side of the migration, before, during and after cutover. We cover the full argument in The VMware pricing problem in 2026: your backup history is the hostage.

A migration plan that survives contact

• Pilot on sacrificial workloads first. One Windows guest, one Linux guest, the oldest OS versions you have. The pilot exists to surface driver and network surprises where they cost nothing.
• Replicate in parallel rather than convert one-shot. Keep the source running while the destination copy syncs incrementally. Cutover becomes a final delta plus a boot, not a long blackout window.
• Test-boot every converted guest before cutover. A migration you have not booted is a theory. Boot it on an isolated network, check drivers, check the IP landed, check the application answers.
• Write rollback criteria before you start. The source stays untouched and protected until the destination has earned trust; decommissioning has its own gate, after retention is solved.

How Sendense automates the breakage points

Sendense treats VMware-to-CloudStack migration as replication with a cutover, not a copy job: the destination copy is kept in sync incrementally, conversion (drivers, initramfs, guest tooling) happens automatically on the way through, and AsureDense boot validation proves each workload actually starts before you commit. Because recovery points live in a platform-neutral repository, the backup history you built on VMware remains restorable after VMware is gone — the destination inherits protection on day one instead of starting from a blank slate. The full path is on the VMware exit solution page.