Migration · VMware
Migrate VMware virtual machines to Apache CloudStack
Apache CloudStack can import virtual machines from VMware vCenter and, from version 4.19, convert them to KVM. Doing it safely still takes an inventory, a target zone, a trial and a cutover plan per machine. In the 30 working days of NexCMP Source an expert engineer does that work with you at no extra charge.
Included with NexCMP Source ($499 one-time), not with NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor and Apache CloudStack are trademarks of their respective owners. NexCMP is independent and not affiliated with or endorsed by them.
The problem: leaving VMware without losing control
Moving to Apache CloudStack means every virtual machine changes platform: its disks, network cards, drivers and often its addresses. Done in a hurry, this is where machines fail to boot, customers lose access or licenses stop working.
CloudStack provides the import tools, but it does not decide for you which machines go first, how each network is mapped, what happens to Windows guests, or how long each machine will be offline. Those decisions, and the testing around them, are the migration.
If you sell the virtual machines to customers, the move has a second half: the machines must end up attached to the right customers, plans and prices in your billing system. NexCMP is that billing and customer portal layer on top of CloudStack, and the same engineer handles both halves.
What CloudStack itself supports
There are two documented routes from VMware. Which one fits depends on whether VMware hosts stay in your cloud.
A. Convert to KVM with virt-v2v
- What CloudStack documents
- From version 4.19 an administrator can select a VMware VM in an existing or external vCenter datacenter and import it into a KVM cluster, under Tools, Import-Export Instances. The VM is exported, converted with virt-v2v and its disks are imported as QCOW2. The latest documentation adds a VDDK-based streaming path next to the OVF-based one; version 4.22 added direct conversion to a storage pool and version 4.22.1 guest OS selection based on the source guest OS.
- Limits stated in the documentation
- virt-v2v is not installed by the CloudStack agent and must be installed on each KVM host, or the conversion fails. Success is not guaranteed and depends on the guest OS and file systems, so the documentation recommends testing before production use. The imported VM gets the default guest OS type CentOS 4.5 (32-bit) in 4.19 and must be edited afterwards.
Source: Apache CloudStack — Importing VMware VMs into KVM · accessed 2026-10-19
B. Import in place (unmanaged instances)
- What CloudStack documents
- For vSphere clusters whose hosts are already part of CloudStack, listUnmanagedInstances lists the VMs and importUnmanagedInstance brings them under CloudStack management. Listing unmanaged VMware instances began in 4.14, unmanaging in 4.15 and the import in the UI in 4.16.
- Limits stated in the documentation
- The target network must already exist in CloudStack, and storage must be added as primary storage. Data disks must be mapped to disk offerings, and mixed disk controller types or mixed NIC types cause an error. A running VM can be imported only if the network VLAN and the compute offering match; otherwise it must be stopped first.
Source: Apache CloudStack — About Import Export Instances · accessed 2026-10-19
Route A applies when the destination is KVM. NexCMP's own documentation names KVM as the tested hypervisor, so we plan route A unless your design keeps VMware hosts under CloudStack. Check the CloudStack version you run: the pages above describe different behaviour between 4.19 and the latest release.
What moves and what needs attention
Disks
- What happens
- Converted to QCOW2 and imported into the primary storage pool of the destination (route A), or mapped to CloudStack disk offerings (route B).
- Attention
- In route B a disk is not resized if its disk offering is larger. Temporary storage during a route A conversion is secondary storage by default; primary storage can be used for it only if it is NFS.
Source: Apache CloudStack — Importing VMware VMs into KVM · accessed 2026-10-19
Networks
- What happens
- Networks must exist in CloudStack before import. A discovery script lists the vCenter networks that have at least one VM attached, so the matching networks can be created.
- Attention
- virt-v2v cannot reconfigure a guest's network configuration or change its MAC address. If the target subnet differs, the guest needs changes after conversion.
Source: libguestfs — virt-v2v manual · accessed 2026-10-19
Linux guests
- What happens
- A running Linux VM can be imported by route A: CloudStack clones it before export, so it is converted in a crash-consistent state.
- Attention
- The CloudStack documentation recommends powering Linux VMs off first. virt-v2v does not install new kernels or drivers, and warns if virtio support is missing, so the guest must meet the minimum versions before conversion.
Source: libguestfs — virt-v2v manual · accessed 2026-10-19
Windows guests
- What happens
- Must be shut down gracefully before import by route A. virtio drivers are taken from the virtio-win package and installed on first boot; Windows can reboot four or more times after the first boot.
- Attention
- Fast Startup or hibernation prevents conversion, and a system disk on a Dynamic Disk is not supported. Importing Windows needs virtio drivers on the conversion host.
Source: libguestfs — virt-v2v manual · accessed 2026-10-19
VMware Tools
- What happens
- virt-v2v attempts to remove VMware Tools.
- Attention
- The manual says the removal does not work reliably on Windows, where Tools may have to be removed by another method.
Source: libguestfs — virt-v2v manual · accessed 2026-10-19
Guest OS type
- What happens
- The imported VM gets a default guest OS type.
- Attention
- In 4.19 it is CentOS 4.5 (32-bit) and must be changed by hand; version 4.22.1 can map it from the source guest OS if mappings exist.
Source: Apache CloudStack — Importing VMware VMs into KVM · accessed 2026-10-19
Billing and customers
- What happens
- Plans, prices and customer accounts are set up in NexCMP, and each migrated machine is attached to the right customer.
- Attention
- Agreed in week 1 for your CloudStack version. This is NexCMP work, not a CloudStack feature.
The plan, week by week
Typical, adjusted to your case. The 30 working days of continuous work are about six calendar weeks.
Week 1 — Inventory and decisions
With read-only access to vCenter we list every VM: guest OS, disks, network cards, VLANs, snapshots, power state and what depends on what. We choose route A or B, define the waves and note machines that need special care, such as Windows guests, large disks and anything with a fixed license.
Week 2 — Build the target
The CloudStack zone is checked or built: KVM hosts, storage, networks matching the VMware ones. We install virt-v2v on the KVM hosts (and nbdkit on Ubuntu hosts), prepare virtio drivers for Windows, and open the network paths between the conversion hosts and vCenter and ESXi. If you sell the machines, NexCMP is installed and connected to CloudStack in the same week.
Week 3 — Pilot
A few non-critical machines, one for each kind of guest you have, go through the real procedure. We check that they boot, have network and the right drivers, set the guest OS type, and measure how long each machine is offline. The result sets the windows for the waves.
Weeks 4 and 5 — Waves
Machines move in groups at the times you agreed. Each group is checked before the next starts, and the original VMware machines stay powered off but kept so that you can go back. If you sell the machines, customers, plans and prices are set up in NexCMP alongside, and billing runs in parallel before you switch.
Week 6 — Final cutover and handover
The last machines move, the billing date is switched if you sell them, and DNS changes are made. We write down how everything was done, review hardening and backups, and stay available for the move until the end of the 30 working days.
Outline only. The real plan comes out of week 1, and the only dated commitment in the offer is the 30 working days.
Risks and how we reduce them
No migration is risk-free, and we do not promise zero downtime. This is what can go wrong and what we do about it.
Downtime per machine
Windows machines cannot be converted while running, and a running Linux machine is converted in a crash-consistent state. CloudStack does not state how long a conversion takes. We measure it in the pilot, then agree a stop window per group of machines.
A conversion does not succeed
CloudStack states that success is not guaranteed and depends on the guest. We test each kind of guest in the pilot before any wave, and the original machine stays untouched until the new one has been checked.
Drivers and VMware Tools
Windows machines get virtio drivers during conversion, Linux machines need virtio support beforehand, and VMware Tools may need manual removal. These are checked per guest in the pilot.
IP addresses, MAC addresses and DNS
Guests keep their MAC addresses and their own network configuration, so a different target subnet needs changes inside the guest. We list every address in week 1, lower DNS TTLs ahead of the cutover and tell your customers in advance.
Guest software licenses
Windows and commercial software inside a machine may be licensed to the old platform. We list them in the inventory so you can confirm the terms with each vendor before the move.
Interrupted conversions
CloudStack states that restarting management servers during a migration interrupts it and the import has to be started again. We schedule waves around maintenance and avoid restarts while one is running.
Billing cut-over and rollback
If you sell the machines, the date billing moves is chosen with you and both systems run in parallel first. The VMware originals are kept until you agree the move is finished, which gives every group a way back.
Who does what
Read-only vCenter access and a list of the machines you consider critical
- The expert does
- Inventories every VM and plans the waves
Access to the CloudStack environment and the KVM hosts, or the hardware to build them
- The expert does
- Prepares the zone, networks and the conversion hosts
The VDDK and virtio packages your chosen route needs, where the vendors require you to download them yourself
- The expert does
- Installs and tests them on the conversion hosts
Agreed stop windows and notices to your customers
- The expert does
- Runs the pilot and the waves, and checks every machine afterwards
Your pricing decisions, if you sell the machines
- The expert does
- Sets up plans, customers and billing in NexCMP and runs the parallel period
What you get in the 30 working days
The migration is part of the NexCMP Source upgrade: a one-time $499 that includes the complete source code (Rust server, Vue portal and admin, Go node agent, CLI, build scripts), the right to modify and build your own version without limit, 12 months of new source releases, all apps and 30 working days of continuous work with an expert engineer.
In those 30 working days the expert migrates you from VMware to Apache CloudStack at no extra charge. Instead, or as well, the same time can be used for migrating from WHMCS or another system, or for a full A-to-Z setup and building your apps. The clock starts when you start the work with the expert and is shown on your license page. Support for the move lasts the same 30 days.
NexCMP Free does not include this. Free is free for one year with all modules and no technical support, only fixes of source-code bugs, and renews at $99 per year.
VMware to CloudStack — frequently asked questions
What does it cost?
Is this included in NexCMP Free?
Which CloudStack and VMware versions are supported?
Will my virtual machines have downtime?
Can every VM be converted?
Do I have to keep VMware afterwards?
What do I need to provide?
Sources and notes
Technical statements come from the official Apache CloudStack documentation and the virt-v2v manual. Documentation changes between releases, so check the version you run. The 4.19 statement is from the 4.19 documentation, which opens the VMware-to-KVM page with 'As of CS 4.19'. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor and Apache CloudStack are trademarks of their respective owners. NexCMP is independent and not affiliated with or endorsed by them.
Leave VMware with an engineer at your side
Upgrade to NexCMP Source for $499 and start your 30 working days, or ask [email protected] about your environment first.
Last updated: