Move a VMware VM to a KVM VPS: Convert VMDK or OVA to QCOW2 Step by Step

To move a VMware virtual machine to a KVM VPS, you export it as an OVA or VMDK, convert the disk to QCOW2 with qemu-img (or virt-v2v, which also swaps in the right drivers), make sure the guest can boot from VirtIO disks, and then load the image onto the new server. A typical Linux VM with a few gigabytes of data takes an evening. Windows takes a little longer because the drivers have to go in before the move, not after.

We tested every command below on Debian 13 with QEMU 10.0.13 and virt-v2v 2.6.0, using a real Debian disk that we first turned into the VMware formats you will meet in practice: a normal VMDK, a split VMDK and the compressed kind found inside OVA files. The whole job in five moves:

1. Prepare the guest while it still runs on VMware: VirtIO drivers in, VMware Tools out, network details written down.
2. Shut it down cleanly and export it as OVA, OVF or plain VMDK files.
3. Convert the disk to QCOW2 on any Linux machine and check it.
4. Boot it once on your own computer to prove it starts.
5. Send it to us, and we import it onto your RS Computers VPS or VDS.

Why small VMware shops are moving now

Since Broadcom closed its purchase of VMware on 22 November 2023, the economics for small users have changed one rule at a time. Perpetual licences stopped being sold in December 2023 and everything moved to subscription bundles. From 10 April 2025 the minimum order became 72 cores per product, so a shop with a single 16-core host now pays for 72, as heise reported at the time, with a 20% penalty for renewals made late.

The cheap way out has narrowed too. Free ESXi came back in April 2025 with 8.0 Update 3e, but Broadcom's own note limits it to two physical CPUs and eight vCPUs per VM, without vCenter, without the backup API and without support. vSphere 7 left general support on 2 October 2025, so those hosts no longer get regular patches.

Plenty of people are acting on it. In a CloudBolt survey of 302 large North American companies published in February 2026, 86% said they were actively reducing their VMware footprint (CloudBolt sells migration tooling, so read it with that in mind). Gartner expects 35% of VMware workloads to run on another platform by 2028, according to The Register. In Europe, the cloud providers' association CISPE filed a formal competition complaint in March 2026, citing cost increases of more than 1,000 percent.

A big company rebuilds its private cloud. A small business with three to ten VMs usually just wants them running somewhere sensible next month. That is what this guide is for. If you are planning a whole platform instead, our article on moving from VMware to OpenStack covers that route.

Two ways to move: rebuild, or bring the whole disk

Before converting anything, decide whether the disk should travel at all. Sometimes the quicker path is a fresh server with the same operating system, then copying the data and configuration across.

For the rebuild route, our guides to moving a website to a VPS, databases on a VPS and Docker on a VPS cover the usual pieces. The rest of this article is the whole-disk route.

Step 1: prepare the VM while it still runs on VMware

This is the step most guides skip, and it is the reason most failed migrations fail. On VMware, the virtual disk is attached through a VMware controller (PVSCSI or LSI Logic) and the network card is a vmxnet3. On KVM, both become VirtIO devices. If the guest has no VirtIO driver available at boot, it cannot find its own disk.

Linux guests: check that the boot image knows VirtIO

Linux loads its first drivers from a small file called the initramfs. Debian and Ubuntu build it with most storage drivers included, so they usually boot on KVM without changes. Red Hat, AlmaLinux, Rocky and Fedora build it only for the hardware they are running on, so a VM built on VMware often lacks the VirtIO drivers and stops at boot with a dracut timeout.

On Debian or Ubuntu, check it:

# as root on the VMware VM (Debian or Ubuntu)
lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio_(blk|scsi|net)'

You should see three lines ending in virtio_blk.ko.xz, virtio_net.ko.xz and virtio_scsi.ko.xz (the exact folder names depend on your kernel). If nothing prints, add the four names virtio_pci, virtio_blk, virtio_scsi and virtio_net on separate lines to /etc/initramfs-tools/modules and run update-initramfs -u -k all.

On AlmaLinux, Rocky, RHEL or Fedora, rebuild it with the drivers added, then check:

# as root on the VMware VM (AlmaLinux, Rocky, RHEL, Fedora)
dracut -f --add-drivers "virtio_blk virtio_scsi virtio_net virtio_pci"
lsinitrd | grep -oE 'virtio_(blk|scsi|net)' | sort -u

Expected output: virtio_blk, virtio_net and virtio_scsi. We ran exactly this on AlmaLinux 9 with kernel 5.14.0-687; virtio_pci does not show up in the list because it is built into the kernel, which is fine.

Linux guests: three more things to write down

• Your current network settings: ip -br addr and ip route. The card name will change, and your public IP will be a new one.
• How /etc/fstab names the disks. Lines with UUID= survive the move; lines with /dev/sda1 may not, because a VirtIO disk is called /dev/vda. blkid shows the UUIDs if you need to switch.
• Whether the VM boots with BIOS or UEFI: [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS. Tell us the answer when you send the image.

Finally, swap the guest tools: remove open-vm-tools and install qemu-guest-agent (both package names are the same on Debian 13 and AlmaLinux 9). The agent stays idle until it lands on KVM.

Windows guests: drivers first, then VMware Tools out

Windows is strict about its boot disk driver. Move it without the VirtIO storage driver and it stops with the blue screen INACCESSIBLE_BOOT_DEVICE (0x7B), which Microsoft describes as Windows losing access to the system partition during startup. The order that works:

1. Download the current VirtIO driver ISO for Windows (virtio-win, version 0.1.302 at the time of writing, about 877 MB) inside the VM, open it and run virtio-win-guest-tools.exe. It installs the disk, network and balloon drivers plus the QEMU guest agent.
2. Uninstall VMware Tools from Apps (or Programs and Features) and restart. Do this while still on VMware: Broadcom's own knowledge base says the uninstaller fails once the VM has left vSphere.
3. Turn off Fast Startup (Control Panel, Power Options, "Choose what the power buttons do", untick "Turn on fast startup"). A Windows disk that was hibernated rather than shut down is not safe to convert, and virt-v2v refuses it.
4. Run ipconfig /all and keep the output. If BitLocker is on, suspend it or keep the recovery key at hand.
5. Shut down from the Start menu, not by powering off the VM.

Step 2: export the VM from VMware

Any of these gives you what you need:

• ESXi host client: right-click the powered-off VM and choose Export. You get an .ovf file and one .vmdk per disk.
• vCenter: Actions, Template, Export OVF Template.
• VMware Workstation: File, Export to OVF, and pick .ova as the file type for a single file.
• Command line: VMware's ovftool can export straight from a host to an .ova.

An OVA is just an uncompressed tar archive with the .ovf description, the disk files and a .mf checksum list inside. Unpack it on Linux with tar -xvf yourvm.ova. The .ovf is a readable XML file that tells you the CPU count, memory and whether the VM used EFI, which helps you pick a plan.

Step 3: convert VMDK to QCOW2 with qemu-img

Use any Linux machine with enough free disk space for the converted image: your own PC, a Linux VM, or WSL on Windows. On Debian 13 or Ubuntu, install the tools once:

# as a user with sudo rights, on your own Linux machine
sudo apt update
sudo apt install qemu-utils

Go to the folder that holds the VMDK and look at it first:

# as your normal user, in the folder with the exported files
qemu-img info web01.vmdk

You will see something like file format: vmdk, virtual size: 3 GiB and disk size: 1.04 GiB. The virtual size is the size of the disk the VM sees; the disk size is how much space it really uses. Remember the virtual size, because your new plan's disk has to be at least that big.

Now convert it:

# as your normal user
qemu-img convert -p -f vmdk -O qcow2 web01.vmdk web01.qcow2
qemu-img check web01.qcow2

-p shows progress, -f vmdk names the input format and -O qcow2 the output. The check should end with No errors were found on the image.

Three VMware disk layouts trip people up:

• Split disks. If you have db01.vmdk plus db01-s001.vmdk, db01-s002.vmdk and so on, pass the small db01.vmdk (a text file of a few hundred bytes) and keep all the pieces in the same folder. The same goes for ESXi's -flat.vmdk files: give qemu-img the small descriptor next to it, not the big file. We converted a split disk exactly this way.
• Disks from an OVA. These are "streamOptimized", a compressed VMDK variant. qemu-img reads them with the same command; ours converted without any extra option.
• Snapshots. Files named like web01-000001.vmdk are snapshot layers. Delete or consolidate the snapshots in VMware before exporting, so you convert one clean disk.

One myth to ignore: several popular guides tell you to add -S 0 to "keep the image sparse". The QEMU documentation says the opposite. -S 0 switches off the search for empty space, so the output becomes fully allocated. Leave it out.

Make a smaller copy for the upload

For sending the disk over the internet, a compressed QCOW2 is much smaller:

# as your normal user
qemu-img convert -p -c -f vmdk -O qcow2 web01.vmdk web01-upload.qcow2
sha256sum web01-upload.qcow2

In our test the 1.1 GB converted disk became a 416 MB upload file. Keep the sha256sum line it prints and send it with the file, so we can confirm nothing was damaged on the way. Compressed clusters stay compressed only until the guest rewrites them, which is fine for a transfer copy.

The alternative: virt-v2v does the driver work for you

virt-v2v converts the disk and also edits the guest: it rebuilds the Linux initramfs with VirtIO drivers, changes /dev/sda style names in /etc/fstab, removes VMware Tools on Linux and sets up the QEMU guest agent. Debian 13 ships it as a package.

# as root on your own Linux machine (Debian 13), with /dev/kvm available
apt install virt-v2v guestfs-tools
mkdir -p /var/tmp/out
export LIBGUESTFS_BACKEND=direct
virt-v2v -i disk web01.vmdk -o local -os /var/tmp/out -of qcow2

On our test machine this took 26 seconds and printed, among other lines, "This guest has virtio drivers installed." The result is /var/tmp/out/web01-sda (a QCOW2 file, even without the extension) plus web01.xml. For an OVA from vSphere, the input part becomes -i ova yourvm.ova, and virt-v2v needs free space in /var/tmp for a full uncompressed copy of the disks while it works.

For Windows guests, virt-v2v also needs the VirtIO driver ISO, which Debian does not package. Download it as in Step 1 and point to it with export VIRTIO_WIN=/path/to/virtio-win-0.1.302.iso before running the conversion. Even then, install the drivers yourself on VMware first; it is the more reliable order, and the virt-v2v manual warns that removing VMware Tools from Windows during conversion often does not work.

Step 4: boot it once on your own machine

A two-minute test saves a day of guessing. If your Linux machine supports KVM, start the converted disk with a VirtIO disk and network card, the same kind of hardware it will get on our servers:

# as a user with sudo rights
sudo apt install qemu-system-x86
# as root (or a user in the kvm group)
qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -nographic \
  -drive file=web01.qcow2,if=virtio,format=qcow2 \
  -nic user,model=virtio-net-pci

Linux guests that print to a serial console show their boot messages and end at a login: prompt. Ours did, and two lines in the log are worth recognising: virtio_blk virtio1: [vda] means the VirtIO disk driver loaded, and virtio_net virtio0 ens3: renamed from eth0 shows the network card getting a new name. Press Ctrl+A, then X, to stop the test VM. For Windows, drop -nographic on a desktop Linux and watch the window instead.

If it stops with a dracut timeout or a 0x7B blue screen, go back to Step 1; the drivers are missing. The converted file is not lost; fix the original VM, export again and reconvert.

Step 5: choose the plan and send us the disk

Pick a plan whose disk is at least the virtual size from qemu-img info, with memory close to what the VM had on VMware. All plans are KVM virtual machines with NVMe storage, a dedicated IPv4 address, IPv6 and free weekly backups:

Choose the city near your users: Amsterdam for most of Europe, Prishtina for Kosovo and the Balkans, or Dublin for Ireland. Windows Server is chosen at the configure step; our Windows VPS page covers that side.

Then message us on Telegram or email info@rscomputers-ks.com with the operating system, BIOS or UEFI, the virtual disk size and the SHA-256 checksum. We arrange the upload and import the disk onto your VPS or VDS; like other setup work, it is quoted per job.

First boot on the VPS: the things that change

Open the console from the client area for the first login, since the network may not be up yet.

Linux: the network card has a new name

On VMware the card was usually ens192, ens160 or ens33; on KVM it gets a name from its new slot, such as ens3 or ens18. Your old configuration still points to the old name, so the server comes up without network.

# as root, in the VPS console
ip -br link
grep -rn ens192 /etc

The first command shows the new name. The second finds every file that still uses the old one (replace ens192 with your old name): /etc/network/interfaces on Debian, /etc/netplan/*.yaml on Ubuntu, NetworkManager files on Red Hat systems, and sometimes firewall rules. Put in the new name and the IPv4 and IPv6 addresses from your service details, then restart networking or reboot.

Linux: tidy up

If VMware Tools are still installed, remove open-vm-tools. Make sure qemu-guest-agent is installed and running (systemctl enable --now qemu-guest-agent), and check that the clock is right with timedatectl.

Windows: a ghost network card and activation

Windows keeps the old vmxnet3 adapter as a hidden device with your old static IP attached, and refuses to give the same address to the new card. In Device Manager choose View, Show hidden devices, open Network adapters and uninstall the greyed-out VMware adapter. Then set the new address on the VirtIO adapter.

A hardware change this large can deactivate Windows. Microsoft's reactivation guide covers Windows 10 and 11. For Windows Server licences you bring yourself, Microsoft's Flexible Virtualization Benefit allows licences with Software Assurance or a subscription to run on a hosting provider's shared servers; plain OEM or retail licences are not covered, so check what you own before the move.

When the converted VM will not start

Keep the original VM switched off but not deleted on VMware until the new server has run for a week. It is your rollback.

Frequently asked questions

How do I convert VMDK to QCOW2?

Install qemu-utils on Linux and run qemu-img convert -p -f vmdk -O qcow2 disk.vmdk disk.qcow2, then qemu-img check disk.qcow2. For a split VMDK, give the small descriptor file, with all the pieces in the same folder.

Should I use QCOW2 or RAW?

QCOW2 is the better transfer format: it only stores the used space, and with -c it is compressed as well (our 1.1 GB test disk became 416 MB). RAW is a plain byte-for-byte copy, as large as the whole virtual disk unless the file system stores it sparsely. Either can be imported.

Can I convert a VMware VM on Windows?

The easiest way is a Linux environment on the Windows PC, such as WSL with Debian or a small Linux VM, then the same qemu-img commands. The Windows guest itself must be prepared inside VMware first, as in Step 1.

Does qemu-img convert change anything inside the VM?

No. It only changes the container format of the disk; the guest is copied as it is. That is why drivers and network names have to be handled separately, or with virt-v2v, which does edit the guest.

Can RS Computers do the migration for us?

Yes. Send us the converted image and we import it onto your VPS or VDS, or tell us what runs on the VM and we will suggest whether a rebuild or a disk move fits better. Message us on Telegram or email info@rscomputers-ks.com.

A checklist to print

On VMware: consolidate snapshots, check the initramfs on Linux or install virtio-win on Windows, remove VMware Tools, note the network settings and the firmware type, shut down cleanly. On your Linux machine: qemu-img info, qemu-img convert, qemu-img check, a test boot, a compressed upload copy and its sha256sum. With us: pick a plan at least as big as the virtual disk, send the details, and fix the network name at first boot. Keep the old VM for a week, then let it go.

← All articles