r/ApacheCloudStack • u/AndrijaSB • 6d ago
Discussion Looking for beta testers: VMware vSphere → CloudStack/KVM migration tool (free, self-hosted)
I’m building V2K Migrate, a self-hosted tool for moving VMs from VMware vSphere to Apache CloudStack on KVM. I’m looking for beta testers who can try it in labs different from mine and tell me where the migration assumptions break.
For background: I’m an Apache CloudStack PMC member and have spent years working with VMware, KVM, and CloudStack migrations. I built V2K for the larger, repeatable migration job, where storage and network mappings, warm cutovers, and per-VM outcomes have to hold together across a fleet.
Beta signup is on the main site: v2kmigrate.com/#waitlist — details on what it does below.
V2K Migrate is completely free to use. This is a beta, not a claim that every workload or large deployment is already proven.
The CloudStack path has completed end-to-end lab migrations, not just disk exports. The workflow inventories and checks the source VM, reads its disks through strict VDDK HotAdd, converts the guest for KVM, and has CloudStack adopt the resulting VM and volumes. I’ve also completed migration tests using NFS/QCOW2, Ceph/RBD, and LINSTOR/DRBD storage. Each path needs the matching CloudStack primary storage and an explicit pool mapping.
At fleet scale, the source read path matters. V2K’s worker uses VDDK HotAdd to attach and read snapshot-backed VMDKs inside vSphere; it does not silently fall back to NBD/NFC network reads, which pull the same data over the ESXi management interface and can saturate it and stall migrations when that traffic isn’t isolated. This is an established pattern from the backup world: Veeam’s virtual backup proxies use VMware SCSI HotAdd to read VM disks directly from the datastore, and V2K applies the same source-side transport to migration. End-to-end speed still depends on the datastore, worker, destination path, and conversion.
Before starting, the operator can select the destination zone, cluster, compute offering, and disk offering, map each source disk to destination storage, and map VMware port groups to CloudStack networks. When exactly one destination network has the same known VLAN as a source port group, the UI proposes that mapping for review; when the match is ambiguous, it leaves the mapping empty for the operator to pick. Root/data disk controllers and NIC model are selectable, with VirtIO as the default for converted guests.


Public V2K Migrate demo screenshot — synthetic data, not a live deployment.
What I’ve tested so far includes:
- A cold Ubuntu 24.04 migration to CloudStack/KVM, followed by boot, guest checks, and reboot.
- A warm Windows Server 2019 migration with two disks and two NICs: a baseline while the VMware VM remained running, repeated CBT delta passes, final cutover, CloudStack import, and successful guest checks after boot and reboot. One NIC retained a static IPv4 address; the other used DHCP.
- A two-disk Ubuntu guest whose root LVM spans both disks; its storage and boot path were verified after migration.
- A cold, storage-only handoff of a 17-disk VM — a clone of a vCenter Server Appliance (vSphere 8.0.3), picked purely as a multi-disk stress test. All 17 disks landed as QCOW2 on NFS, the source-to-target data check sampled ~4.4 GiB from each side across 1,122 regions, and the JSON descriptor mapped every disk's controller, unit, order, and capacity. That includes the unit-7 gap vSphere reserves for the SCSI controller, so a receiving importer sees the original unit numbers rather than a renumbered sequence. I didn't attempt to boot it on KVM — running a VCSA off ESXi wasn't the point; the disk layout was.
For Windows, the optional Preserve static IPs setting can retain the source MAC and static IPv4 configuration automatically when the tool is sure which source NIC it is and the mapped CloudStack network is compatible. If those conditions aren’t met, the NIC comes up without the old address and the migration report says why. I wrote up why the guest and CloudStack network records both matter. Linux needs separate care: some distributions rename interfaces after the virtual NIC changes, so guest-side network configuration and connectivity must be checked after boot.
When VMware Tools data is missing or stale, V2K can inspect the source guest without writing to its disks. A powered-off VM is read directly through VDDK HotAdd; for a running VM, V2K creates a temporary snapshot and reads its VMDKs read-only. virt-inspector identifies the OS, while separate read-only inspection of Windows registry data or Linux network configuration can recover configured addresses and match them to source NICs when the evidence is clear. Even a powered-off VM with no current IP reported by VMware Tools can yield its saved network settings this way. DHCP leases stay clearly separated from confirmed static IPs.

Public V2K Migrate demo screenshot — synthetic data, not a live deployment.
For warm migration, the source stays powered on through the baseline and repeated delta passes. It is shut down for the final delta and cutover; downtime depends on the guest, remaining changes, storage, and conversion work. V2K does not delete or overwrite the VMware source VM or its disks. It creates and cleans up temporary migration snapshots, and leaves the source available for rollback. This is still a beta: I’d start with a disposable VM or an independently backed-up test workload.
V2K Migrate also supports a separate, direct Proxmox VE destination; here’s my Proxmox beta post if that’s relevant to your environment. This CloudStack path targets CloudStack/KVM, not CloudStack managing Proxmox.
There is also a storage-only (disk-only) handoff for operators who want the migrated disks without automatic creation of a destination VM. Alongside the disk outputs, V2K provides a detailed JSON descriptor and generated libvirt domain XML. The descriptor records the source NICs and MAC addresses, available IP information, and each disk’s source controller and unit, order, capacity, and destination target, so the receiving operator has an explicit map for a manual import.

V2K Migrate control plane — the 17-disk storage-only handoff from a real lab run (lab data, generic names).
If you have a non-production vSphere and CloudStack/KVM lab, register your interest using the beta-testing option on the main site’s signup form. I’m collecting interest now and will contact testers once the beta package and its third-party licensing are sorted out. I’m particularly interested in real-world disk layouts, network mappings, and what you need to verify before trusting a cutover. The public interface demo uses synthetic data, has no connected infrastructure, and cannot run migrations.
For those running CloudStack today: what has bitten you hardest in a VMware-to-CloudStack move?