Migration from VMware to WebDisk Cloud: what to move, in wha

WebDisk Blog · category: Public cloud · reading time: ~10 minutes

In brief:- After Broadcom took over VMware, the licensing model and the partner program changed, so at support renewal time more and more companies are running the numbers on alternatives. The one considered most often is KVM managed by Apache CloudStack – because the way you work with it is close to what an administrator knows from vCenter.- Two paths: move machines and networks to the WebDisk public cloud, or deploy CloudStack on your own premises, with our support. Both can be run in stages, in parallel with a live vSphere.- The technical core is three methods (OVA/OVF, converting disks to qcow2, system-level synchronization), one classic pitfall (virtio drivers) and one thing you cannot skip: a rollback plan. >Not a terminal person? Skip the command blocks – the order of work, the pitfalls and the checklist are all described in words.

The conversation usually starts the same way: the IT department receives a renewal quote for vSphere support, looks at the terms, looks at the budget and, for the first time in years, asks itself "do we actually have to?". After Broadcom took over VMware (the deal closed at the end of 2023), several things changed at once: the portfolio was consolidated into large bundles, perpetual licenses gave way to subscriptions, and the 2024 rebuild of the partner program changed the list of companies allowed to sell and renew licenses. The financial impact depends on your specific contract, not on a blog article – which is why, instead of percentages, what you get here is a plan of action in case your own calculations come out unfavorably.

In this article we show what to move and in what order, three methods of moving a machine, and where migrations most often fall apart – with a single-machine checklist and a rollback plan. The text is for IT teams facing a vSphere support renewal: the administrators who will be doing the work, and the people who have to estimate the risk and the budget.

Two paths: our cloud or CloudStack on your premises

Path one – the public cloud. You move your machines and networks to the WebDisk public cloud, you stop maintaining your own hypervisor (a hypervisor is the software that runs virtual machines on a physical server) and you manage the environment from the WebDisk Cloud panel. A Kubernetes cluster is rebuilt in the new environment – with us as the WebDisk K8s service – by moving workloads and volumes, not machines. Billing is monthly, for the pool of resources you buy, with a public price list in euro – so the cost comparison is made on your own numbers: the total of vCPU, RAM, capacity and transfer, set against the full cost of your own server room, including power, hardware replacement and people's time.

Path two – CloudStack in your own server room. You stay on your own hardware but take the licensing dependency off it: Apache CloudStack is free software (Apache 2.0 license) developed by the Apache foundation. Our role is then support, and its scope – design, deployment, moving the machines, training the team – is agreed individually. The two paths can also be combined – part of the environment on your side, part on ours; how the two locations are connected is settled during the design phase.

It is worth being blunt here: if you do not deliberately choose an open layer, you are only swapping one dependency for another – which we wrote about in our article on vendor lock-in.

Why is CloudStack the natural alternative to vSphere?

For a vSphere administrator, CloudStack is a soft landing – for concrete reasons, not out of sympathy:

The operating model is familiar. The hierarchy of zones, pods, clusters and hosts mirrors what vCenter calls datacenter → cluster → host, and the work happens in a single web panel. CloudStack is monolithic, so it is simpler to deploy and maintain than platforms assembled from a dozen or more components.
One orchestrator, many hypervisors. CloudStack manages KVM, but also VMware vSphere or XCP-ng. That opens up the transition path that is easiest to back out of: you run CloudStack alongside a live vSphere, attach the existing cluster as a resource and migrate machines gradually.
Simplified mode for on-premise. A zone can be run without network virtualization – instances go straight into a shared network on your VLANs, which saves companies with tidy addressing an entire layer of complexity. Kubernetes clusters, in turn, have their own platform service: CloudStack sets up the control plane, and you load your own workloads and data into it. If you would rather hand over cluster maintenance, we offer technical support for Kubernetes.
Storage. Our platform is based on Ceph – as block storage for machines and as S3-compatible object storage. Capacity is added by adding nodes, with no downtime for the machines.

Supplementary reading is the public "VMware to Apache CloudStack Migration Guide" from ShapeBlue, a company heavily involved in CloudStack's development.

What to move first, and what last?

The most common mistake is to start with the machine somebody knows best – that is, with the most important one. The order that holds up is the opposite:

Inventory. Export the list of machines from vCenter: vCPU, RAM, disks and how full they really are, IP and MAC addresses, system version, firmware (older BIOS or newer UEFI – the mode the machine boots in), agents, licenses tied to hardware. This spreadsheet is the basis of the schedule.
Dependency map. What talks to what, and over which ports. A machine moved without its database is not a migration, it is an outage on a slow fuse.
Foundations in the new environment. First the network (VPC, subnets, rules, NAT, the connection to your network), then DNS, identity and access, backup and monitoring. Only then do you put machines on top.
Wave zero – one non-production machine. The goal is procedural: to measure how long the transfer and conversion really take, and to rehearse the rollback on something expendable.
Wave one – stateless services. Application servers, front ends, auxiliary machines. The cutover is cheap, because the data does not migrate with the machine.
Wave two – data. Large volumes are worth "seeding" in advance (a full copy ahead of time, only the difference during the window), and archives are worth moving straight to object storage instead of hauling them around inside a virtual disk.
Final wave – critical systems, by now on a rehearsed procedure.

Before the first wave, make a backup outside both environments – a migration is the only moment when the same data exists in two places and both are in motion (the rules are described in our article on cloud backup, and WORM-class storage – storage in which a written copy cannot be overwritten or deleted before its deadline – is covered in our article on S3 Object Lock).

How to move a virtual machine from VMware to KVM? Three methods

Method A – OVA/OVF export (OVA and OVF are the standard formats for exporting a virtual machine to a file). The classic: the machine is shut down, exported to a single file and imported on the other side. Predictable, but it requires a full maintenance window and room for two copies of the disk.

# exporting a machine from vSphere to OVA (ovftool, from a host with access to vCenter)
ovftool --noSSLVerify \
vi://uzytkownik@vcenter.firma.local/Datacenter/vm/app-01 \
./app-01.ova

Method B – disk conversion. You convert the VMware format (VMDK) into the format native to KVM (QCOW2 or RAW) and register it as a template or a volume.

# unpacking the OVA and converting the disk VMDK -> QCOW2
tar -xvf app-01.ova # -> app-01.ovf, app-01-disk1.vmdk
qemu-img convert -p -f vmdk -O qcow2 app-01-disk1.vmdk app-01.qcow2
qemu-img info app-01.qcow2 # check: format and virtual size

The safer option is virt-v2v: it converts the image and at the same time injects into the guest system the drivers needed under KVM – that is, it takes care of the biggest pitfall from the next section. There is one condition: for Windows machines the virtio-win drivers must be installed on the machine you convert on. Without them the conversion will succeed, but the system still will not boot.

# conversion + preparing the guest system for KVM in a single step
virt-v2v -i ova app-01.ova -o local -os /var/tmp/wynik -of qcow2

You publish the finished image over HTTP(S) and register it in CloudStack as a template (the "Register template" form in the panel, or register template in cloudmonkey – QCOW2 format, KVM hypervisor). Newer releases can also pull a machine straight from vCenter and convert it to KVM without moving files by hand; availability depends on the version, so check it on your own deployment before you build the schedule.

Method C – system-level synchronization. Instead of hauling the disk, you build a clean machine in the new environment, install the software and move the data. That way you do not drag along old drivers, leftovers from VMware Tools or the history of upgrades.

# first pass – live, the source is still running
rsync -aHAX --numeric-ids --info=progress2 root@stara-vm:/srv/ /srv/

# closing pass – during the maintenance window, after stopping the services;
# it moves only the difference, which is why the window is short
rsync -aHAX --numeric-ids --delete root@stara-vm:/srv/ /srv/

In practice: A for simple, single machines; B for appliances – ready-made machines from a software vendor that you cannot set up from an installer; C for everything you would build from scratch – and everywhere a short window matters.

Pitfalls that eat up the maintenance window

Virtio drivers. Number one on the list. Virtio is the family of drivers a virtual machine uses to talk to disk and network under KVM. Windows without previously installed virtio drivers will not boot (the classic "inaccessible boot device" stop error); Linux with an initramfs – a small boot-time system in memory, loaded before the actual disk comes up – built without virtio modules will halt on a missing disk. The cure is simple, provided you apply it before shutting down the source machine: install the drivers and rebuild the initramfs, or use virt-v2v – on condition that the machine you convert on has the virtio-win drivers installed; without them the conversion will succeed, but Windows still will not boot.
Network interface names. A new card type means a new interface name (ens192 can turn into ens3). A configuration pinned to the old name or to a MAC address means a machine that boots with no network. Review netplan, the ifcfg files and the udev rules before the move.
MAC addresses, licenses and snapshots. Some software ties its license to a MAC address, a machine UUID or a mainboard serial number – make a list of such systems early, because re-licensing is handled before the migration, not during the maintenance window. Machines with a chain of snapshots should be migrated only after consolidation: an export with an active chain is the shortest route to an image that will not boot.
VMware Tools, UEFI and fstab. Uninstall VMware Tools before the migration and install qemu-guest-agent on the other side. A machine that boots in UEFI has to land on a UEFI instance (the mismatch shows up as a "black screen for no reason"), and an fstab – the file listing the disks mounted at system start – written with device names instead of UUID identifiers is a guaranteed boot failure once the disk controller changes.
Transfer time and DNS. Work out the copying time in advance – capacity divided by the real throughput of the link; a few dozen terabytes is not a job for one weekend. And lower the TTL of your DNS records – the time for which servers and browsers keep the old answer in memory – a day before the cutover, because otherwise the cutover takes as long as the longest cache along the way – and the rollback exactly as long.

Test and rollback plan

A migration with no defined rollback is not a migration, it is a bet. The minimum to put into the procedure:

Acceptance criteria (before traffic goes to the new environment): the system boots after two restarts; the console from the panel works; addressing, routes and DNS match the design; the service passes an end-to-end test (not "the process is running", but "a user completed an operation"); disk performance compared with the state before the migration; the backup ran and was test-restored; monitoring – yours or agreed with us – sees the machine and raises alerts.

Rollback: the source machine stays shut down but untouched for an agreed period (a sensible minimum is two weeks of stable operation). Define the point of no return – the moment when writes appear in the new environment that do not exist in the old one: up to that point backing out is free; after it, backing out means migrating the data back. Also settle who announces the decision and the hard hour at which it is made ("if we do not have a green test by 4:00, we go back") – at three in the morning nobody wants to be the one who first proposes a retreat.

Right after the cutover, make sure the machine is covered by your monitoring – and if you want a hung system to restart itself, arm it with a watchdog (the reaction is a hard reset, not a repair).

Single-machine checklist

T-14: inventory and dependencies · re-licensing wherever the license is tied to hardware · virtio drivers installed on the source · a test restore of the backup
T-2: snapshot consolidation · network configuration decoupled from interface names and MAC addresses · first "live" copying pass · verification of the image after conversion
T-1: lowered DNS TTL · maintenance window announced · written acceptance criteria and the hour of the rollback decision
T-0: services stopped · closing data pass · start of the target machine · end-to-end test · traffic cutover
T+1: backup and monitoring confirmed · source machine shut down but preserved · documentation and addressing updated

What will a migration from VMware not solve?

Not every feature has a one-to-one counterpart. Automatic cluster load balancing or the distributed firewall from NSX have their own, but different, solutions in the KVM/CloudStack world. Instead of hunting for a carbon copy, check which of them you are actually running today.
Kubernetes clusters are built from scratch. What gets migrated are manifests, images and the data on volumes – not the nodes. Plan this as a separate project, not as one of the machine-moving waves.
The hypervisor is not the whole platform. Backup, monitoring and identity management have to be rebuilt deliberately – that is usually a larger part of the project than moving the disks itself.
A migration has a one-off cost: people's time, maintenance windows, risk. Put that cost next to the savings on licenses before the business side does it for you.
If you stay on your own hardware, you stay a cloud operator. Free software removes the license fee, not the duties: updates, disk replacements, capacity, on-call shifts.

Frequently asked questions

Do I have to migrate everything at once? No – and it is better if you do not. CloudStack manages KVM and vSphere at the same time, so both environments can run in parallel throughout the transition period, and the cutover happens in waves.

Can Windows machines be moved? Yes, provided the virtio drivers are prepared on the source beforehand – or that you use virt-v2v, which will do it during the conversion, as long as the virtio-win drivers are installed on the converting machine (without them the conversion will succeed, but Windows still will not boot). Check the system and application licenses separately – they are sometimes tied to hardware.

How do the three methods of moving a machine differ: OVA/OVF, disk conversion and data synchronization? An OVA/OVF export moves the whole machine as a single file – it is predictable, but it requires a full maintenance window and room for two copies of the disk. Disk conversion (VMDK to QCOW2, ideally with virt-v2v, which injects the drivers at the same time) works well for appliances that you cannot set up from an installer. System-level synchronization – a clean machine in the new environment plus moving the data alone – gives the shortest window and does not drag along any leftovers from VMware.

Why does Windows or Linux fail to boot after migrating from VMware to KVM? The most common reason is missing virtio drivers: Windows ends with the "inaccessible boot device" stop error, and Linux with an initramfs built without virtio modules halts on a missing disk. The other two suspects are a boot-mode mismatch (a UEFI machine started as BIOS) and an fstab written with device names instead of UUID identifiers. The cure is applied before shutting down the source machine: installing the drivers and rebuilding the initramfs, or converting with virt-v2v.

Will my data stay in Europe? Yes. The infrastructure on which we provide our services is located on Polish territory – this is declared in our Privacy Policy; the same document describes the exceptions (analytics and billing data processed by providers outside the EEA under standard contractual clauses). We make the data processing agreement (DPA) together with the list of sub-processors available to customers on request. We described why this is the decisive argument for some organizations in our article on Polish cloud computing.

We want to stay on our own premises. Will you help? Yes – the scope (design, CloudStack deployment on your hardware, moving the machines, training the team) is agreed individually. CloudStack is free software, so once the project is over the environment remains yours.

Summary

Migrating from VMware is not technically hard – it is organizationally hard. Converting a disk takes a few commands; whether the cutover ends at two in the morning or at six is decided by the schedule of waves, the dependency map, drivers prepared in advance and an agreed moment for turning back. And if the ledger is still open and, alongside CloudStack, you are also running the numbers on hyperscalers, our comparison hyperscaler or Polish cloud will help.

The cheapest first step is a conversation and a test on a single machine: we go through your inventory spreadsheet, show you what the work looks like in the panel and tell you outright what will move smoothly and what will take work. Write to us or take a look at the WebDisk public cloud.

Migration from VMware to WebDisk Cloud: what to move, in what order and with what tools