After Broadcom’s acquisition of VMware closed in November 2023, a wave of vSphere customers started looking at alternatives. Apache CloudStack with KVM is one of the most credible destinations: open source, multi-tenant from day one, and shipping a built-in VMware import tool since CloudStack 4.19.
This is the practical guide for a team evaluating the move. ZSoftly operates this migration as a managed service for ZCP customers, but the steps below describe what happens under the hood, whether we run it for you or you run it yourself. The single best reference for the self-serve path is the ShapeBlue VMware to Apache CloudStack migration guide. We cite it where we are summarising their methodology and add the operational notes from running this in production.
What ZSoftly handles vs what you handle
If you are a ZCP Private Cloud Build-Out customer, ZSoftly engineers run the four phases below end to end:
| Phase | We handle | You handle |
|---|---|---|
| Assess | Inventory tooling, sizing, cost model, written architecture | Sharing vCenter read access and signing off on scope |
| Prepare | Provisioning KVM hosts, installing virt-v2v + virtio-win, building CloudStack environment | App-owner sign-off on the cutover window |
| Migrate | Running the conversion (virt-v2v), validating each instance post-boot | Application-level smoke tests |
| Operate | Patching, upgrades, on-call, capacity planning | Application changes and future workload requests |
If you are running this yourself on a CloudStack environment you operate, this guide walks through the same steps you would execute manually or via the CloudStack API.
Phase 1, Assess: profile the vSphere estate
Inventory every VM in scope. For each one, you need: vCPU count, RAM, disk size and type, OS family and version, network attachments (port group, VLAN, subnet), and a workload tag (criticality, dependency, RTO/RPO). The output of this phase is a written migration plan with a per-instance row, not a slide deck.
Two patterns we use in practice:
- Group VMs by size class (e.g. 2 vCPU / 2 GB, 4 vCPU / 4 GB), so a small number of CloudStack Compute Offerings cover the estate. The ShapeBlue example bundles four production + dev VMs into two offerings. In production we typically see five to ten size buckets cover 80 % of the estate.
- Group VMs by environment + tenant (dev / staging / prod, per customer or per business unit), so CloudStack Domains and Accounts map cleanly to the operational reality.
Windows guests in scope require a hard pause and restart for the conversion. There is no live migration for Windows. Linux guests migrate while running in some cases, but at the cost of a longer copy window and the risk of in-flight data drift. Plan a maintenance window for each.
Phase 2, Prepare the destination
KVM hosts
The migration tool runs virt-v2v on a KVM host inside the destination CloudStack cluster. CloudStack supports KVM on Alma Linux 8/9, RHEL 8/9, Rocky 8/9, and Ubuntu 22.04 LTS. ShapeBlue recommends EL9-family hosts (Alma 9 in particular) for a newer virt-v2v build with a measurably higher conversion success rate. We use EL9 by default.
Required packages on each KVM host:
# RHEL / Rocky / Alma
dnf -y install virt-v2v
dnf -y install https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.noarch.rpm
# Ubuntu
apt -y install virt-v2v nbdkit virtio-winThe virtio-win package supplies the Windows virtio drivers injected during the conversion. Skip it on a host and Windows migrations on the host will boot to a STOP error.
A CloudStack cluster has a hard limit of 16 hosts. For large estates you plan multiple clusters and pick the destination cluster per workload in the migration form.
CloudStack environment
The Apache CloudStack environment needs four things in place before you click “Import Instance”:
Domains and Accounts. Domains are organisational containers. Accounts are the units owning resources. Mirror your vSphere tenancy structure here. A common pattern: one Domain per customer or business unit, two Accounts inside (dev, prod), one or more users per Account.
Compute Offerings. Each offering is a vCPU + RAM + clock-speed tuple assigned to a migrated VM. Build them from your size buckets from Phase 1. A “Large” offering at 2 vCPU × 1.5 GHz with 2 GB matches a vSphere VM with 2 vCPU and 2 GB. A migrated VM is assigned exactly one offering. Overshoot it and you pay for capacity you do not use.
Disk Offerings. Optional but useful for workloads with explicit IOPS or storage-class needs. On ZCP this maps to rbd-fast (NVMe), rbd-standard (SSD), or rbd-bulk (HDD).
Networks. Pick the right network type per workload:
| Type | Use when |
|---|---|
| Isolated | Strict isolation between tenants or environments, plus SourceNAT for outbound |
| VPC | Multi-subnet topology with explicit routing rules |
| Shared | Multiple tenants need access to a common service (e.g. an internal load balancer) |
| L2 | Legacy applications with VLAN requirements unmet by the upper services |
Each network gets created under its owning Account. The migration form lets you map a source vSphere port group to a destination CloudStack network per VM.
Phase 3, Migrate: the CloudStack 4.19 import tool
CloudStack 4.19 added a UI-driven import flow for VMware. The path is Tools → Import-Export Instances → Source: VMware → Action: Migrate existing Instances to KVM. You point it at a destination Zone, Pod, and Cluster, then click External to connect to a vCenter outside the CloudStack-managed estate.
What the tool does, in order:
- Connects to vCenter with the credentials you supply.
- Lists Instances on the source ESXi hosts.
- For each Instance you import: copies the VMDK from vCenter into either Secondary Storage (default) or Primary Storage, runs
virt-v2von the chosen KVM host to convert OVA → QCOW2 and inject KVM/virtio drivers, registers the instance in CloudStack under the Domain, Account, Compute Offering, and Network you picked, then boots it.
Per-VM form fields you set:
- Display name and Host name.
- Domain and Account (e.g.
ROOT/Customer01/production). - Project (optional, for CloudStack Projects, which group resources under a single Account).
- KVM host override (optional, pin the conversion to a specific host, useful when only some hosts have
virt-v2vinstalled during a phased rollout). - Temporary storage override (optional, by default Secondary Storage holds the converted disk during conversion).
- Compute Offering, pick the one matching the source spec.
- Network selection, map each NIC to a destination network. The Allow duplicate MAC addresses toggle keeps the original MAC, useful when downstream firewalls or licensing key off MAC.
- IP address, randomly assigned by default, or set explicitly.
The Notification area in the CloudStack UI shows the conversion progress per VM. A typical 100 GB Linux VM converts in 15-45 minutes depending on storage tier. Windows VMs take longer because the driver-injection pass has to run before first boot.
Phase 4, Cut over and operate
Once the import is complete, the source VM stays in vCenter (powered off if you followed the recommendation) and the converted VM lives in CloudStack. Cutover means flipping DNS, firewall rules, and any load-balancer targets from the old VM to the new one. We run the cutover in a planned window with rollback paths in place, the source VM is the rollback.
Post-cutover, an operations checklist we always run:
- Boot test, console access, network reachability.
- Application-level smoke test (the customer owns this, we provide the window and the access).
- Performance benchmark vs the source baseline.
- Snapshot the converted instance and validate point-in-time restore.
- Configure backups according to RPO.
- Move the source VM to an “archive” folder in vCenter for a defined retention period, then decommission.
Critical points teams underestimate
Drawing on ShapeBlue’s “Critical Migration Points” plus what we have seen on the ground:
- Phased order matters. Migrate non-critical instances first. Lessons from the first dozen reshape the runbook for the next hundred.
- Custom scripts. Some workloads need post-conversion tweaks: in-guest agent reinstalls, hard-coded MAC dependencies, license re-activation, time-sync after the move. Plan for this. Do not assume
virt-v2vproduces a fully transparent migration. - Testing and validation per instance. A boot does not equal a working application. The smoke test is the gating step before cutover.
- Backup and rollback. Source vCenter is your rollback for the first 30 days. Do not decommission early.
- Training and docs. Your operations team will be looking at the CloudStack UI on day one. Pair the migration with a runbook handoff and a session walking through the CloudStack API or CLI.
- Post-migration optimization. Compute Offerings sized for a one-off migration are rarely optimal long-term. Plan a 90-day review to right-size offerings, consolidate networks, and tune Global Settings.
Automating at scale
The CloudStack REST API exposes everything the UI does. For estates above a few dozen VMs you script the migration end to end. The minimum set:
| API call | Purpose |
|---|---|
createDomain | Provision the tenant container. |
createAccount | Provision the resource-owning Account inside the Domain. |
createServiceOffering | Define the Compute Offerings matching your size buckets. |
createNetwork | Provision the destination network per Account. |
importVm | Import a VMware VM and convert it through virt-v2v to KVM. |
listUnmanagedInstances | Enumerate the source vCenter inventory programmatically. |
Reference: the CloudStack API reference. ZSoftly operates these calls behind a workflow engine for managed migrations. Customers running this themselves typically wrap them in Ansible or a Python script.
When to bring in an engineering partner
The CloudStack 4.19 import tool handles the common case well: VMs sized within standard offerings, OS images on the supported list, simple networking. Where engineering help earns its keep:
- Mixed estates with hundreds of VMs across multiple tenants and security zones.
- Workloads with hardware dependencies (DPDK, SR-IOV, GPU passthrough, custom kernel modules).
- Compliance constraints needing attested change control around the cutover.
- Customers who want the platform operated after standup.
This is what ZSoftly’s private cloud build-out is for. We scope the architecture, run the migration, and operate the resulting platform end to end. If you are at the “evaluating the move off VMware” stage and want a structured assessment with a real number attached, book a migration assessment.
Sources
- ShapeBlue, VMware to Apache CloudStack: Step-by-Step Migration Guide (2024).
- Apache CloudStack, Apache CloudStack API Reference.
- Apache CloudStack, Importing/Migrating Existing VMs (4.19+).
- Red Hat, virt-v2v(1).