Leaving VMware after the Broadcom acquisition is almost inevitable for mid-sized businesses. License costs have multiplied, perpetual licenses are gone, and the subscription model is mandatory. We help companies migrate to Proxmox or KVM with minimal risks: we perform an inventory, convert each VM, and configure backups and monitoring. Migration is not just a hypervisor swap — it means restructuring each VM for the new platform, changing backup processes, monitoring, and network configuration. Our track record: 5+ years and 50+ successful migration projects. Our service is turnkey VMware to Proxmox/KVM migration. Request a preliminary assessment — we will calculate timelines and costs. Since VMware discontinued perpetual licenses, the annual subscription for 100 VMs costs $10,000–15,000, which is prohibitive for many companies. Proxmox is a free hypervisor based on KVM, offering similar functionality without licensing fees. However, migration requires care: a disk conversion error can lead to data loss.
Why switch to Proxmox/KVM?
Proxmox is not just free. It offers built-in backup, ZFS, clustering, and a web interface comparable to vSphere. Compared to VMware, Proxmox consumes 4 times less RAM (1 GB vs. 4 GB for ESXi). The community actively updates packages, and commercial support is available from several vendors. For businesses, this means a 30-50% reduction in TCO without loss of functionality. For example, license savings for a 100-VM cluster amount to roughly $50,000 per year.
What happens to VMs during conversion
VMware stores disks in VMDK format. KVM and Proxmox use qcow2 or raw. This is not just a file rename — conversion via qemu-img is required. Simultaneously, BIOS/UEFI settings, VMware Tools, and paravirtual drivers must be replaced with KVM equivalents (virtio drivers, qemu-guest-agent).
| VMDK Format | Conversion Result | Comment |
|---|---|---|
| thin | qcow2 (sparse) | Saves space, supports snapshots |
| thick eager-zeroed | raw or qcow2 with preallocation | For high-performance disks |
| snapshot chain | separate qcow2 after merge | vmware-vdiskmanager -r source.vmdk -t 0 flat.vmdk |
How virt-v2v simplifies migration
virt-v2v is the standard tool for migrating from VMware to KVM. It connects to vCenter via API, converts disks, replaces VMware Tools with qemu-guest-agent and virtio drivers. Automated migration via virt-v2v reduces conversion time by 50% compared to manual export/import. Installation on RHEL/CentOS:
dnf install virt-v2v nbdkit nbdkit-vmware-plugin Example VM migration from vCenter (click to expand)
export LIBGUESTFS_BACKEND=direct virt-v2v \
-ic "vpx://vcenter.company.local/Datacenter/cluster01?no_verify=1" \
-it vddk \
-io vddk-libdir=/opt/vmware-vix-disklib-distrib \
-io vddk-thumbprint=$(openssl s_client -connect vcenter.company.local:443 </dev/null 2>/dev/null \
| openssl x509 -fingerprint -sha1 -noout | cut -d= -f2) \
-o local -os /var/tmp/v2v-output \
--root first \
"vm-name-in-vcenter"Output in /var/tmp/v2v-output/: qcow2 disk files and libvirt XML config. For Proxmox, import via qm importdisk.
Why Windows VMs require special handling
Linux VMs migrate relatively smoothly — virtio drivers are built into modern kernels. Windows does not know about virtio, and on first boot after the hypervisor change, it hangs on a blue screen INACCESSIBLE_BOOT_DEVICE or enters a recovery loop.
virt-v2v can prepare Windows VMs for KVM: it adds virtio drivers in offline mode (via libguestfs API), removes VMware Tools, and configures the correct HAL. But this only works if:
- Windows is not BitLocker-encrypted
- The VM is powered off before migration
- Windows has current updates (older OS like Windows Server 2008 require manual driver installation)
Manual path for Windows without virt-v2v:
- Install virtio drivers on VMware (add a virtio disk controller as secondary, boot Windows, install driver, remove device)
- Convert VMDK → qcow2
- Import into Proxmox
- Boot
Network configuration: VMware vSwitch → Linux Bridge/OVS
In VMware, the network is vSwitches with Port Groups. In Proxmox, it is Linux Bridge (vmbr0, vmbr1) or Open vSwitch for more complex topologies. The VLAN configuration must be replicated:
# /etc/network/interfaces on Proxmox node
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
# VLAN-aware bridge for multiple VLANs
auto vmbr1
iface vmbr1 inet manual
bridge-ports eno2
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094Each VM gets a VLAN tag in the config: qm set 200 --net0 virtio,bridge=vmbr1,tag=100.
Migration workflow for a cluster
We perform mass migration in waves, not all VMs at once:
- Pilot: 2–3 non-critical VMs, check functionality, disk and network performance
- Wave 1: Dev/staging environments, no downtime constraints
- Wave 2: Production, secondary services (monitoring, logs, backups)
- Final wave: Production, business-critical — requires a maintenance window
After each wave, a week of observation before the next. Do not decommission VMware prematurely — until everything is stable, the old hypervisor should remain available for rollback.
What is included in the migration service?
- VM inventory: OS, disks, network, dependencies
- Disk conversion (VMDK → qcow2) preserving structure
- Driver and VMware Tools replacement with virtio and qemu-guest-agent
- Network setup: VLAN, bridge, IP addresses
- Testing of each VM after migration
- Documentation of the new infrastructure
- Handover and administrator training
- One week of post-migration support
Why choose us?
- 5+ years of experience with VMware and KVM/Proxmox
- 50+ successful migration projects
- Certified engineers (RHCE, VCP)
- Work guarantee — free issue resolution within one month
- Full documentation and training for your team
Timelines
| Scope | Timeline |
|---|---|
| 5–10 VMs, Linux only | 3–5 business days |
| 20–50 VMs, mixed (Linux + Windows) | 2–4 weeks |
| 100+ VMs, cluster migration | 2–3 months |
Exact assessment after inventory: number of VMs, OS, disk sizes, network topology, downtime requirements. Cost is calculated individually. Contact us for a preliminary estimate. Order a pilot migration of 3 VMs to verify quality.
Note: For migration, we refer to official documentation of KVM and virt-v2v.