Article
Two Paths Off VMware: The VM Way and the Cloud Native Way
Broadcom's licensing overhaul turned renewals into a forced architecture decision. You don't have one exit path, you have two, and the right one depends on where your organization is heading.
Bundled SKUs, perpetual licenses gone, and renewal quotes at 2x-10x. For most infrastructure teams, this isn't a renewal. It's a forced architecture decision on a timeline they didn't choose.
But here's the thing: you don't have one exit path. You have two. And which one you choose depends on where your organization is heading, not where it's been.
The two paths at a glance
| Criteria | Path A: the VM way | Path B: the cloud native way |
|---|---|---|
| Stack | KVM + Proxmox or CloudStack | Kubernetes + KubeVirt |
| Model | Familiar VM lifecycle, minimal application changes | Containers first, VMs where needed |
| Best for | Heavy VM estates and vSphere style ops tooling | Teams investing in GitOps, CI/CD and platform engineering |
| Storage | Ceph | Ceph, through the Rook-Ceph operator |
Path A: the VM way
This is the path of least disruption for teams with large VM estates. You keep the VM abstraction, keep your operational patterns, and swap the hypervisor layer from ESXi to KVM, the same hypervisor that powers Google Cloud, AWS Nitro, and most of the world's Linux virtualization.
Proxmox VE
A web UI, cluster management, live migration and backup, with no per socket licensing. The closest to the vSphere experience.
Apache CloudStack
Multi tenant cloud orchestration with self service portals and API driven provisioning. More an IaaS platform than a hypervisor manager.
Path A migration
- 01
Export
Export VMDKs from vSphere.
- 02
Convert
Convert them into Ceph RBD volumes.
- 03
Recreate
Recreate VM configs in Proxmox or CloudStack.
- 04
Swap agents
Replace VMware Tools with the QEMU Guest Agent.
- 05
Cut over
Move workloads in phased batches.
Path B: the cloud native way
This is the forward looking path. Instead of replacing one hypervisor with another, you adopt Kubernetes as your unified control plane for both containers and VMs. KubeVirt runs traditional virtual machines as Kubernetes pods: same API, same scheduling, same GitOps workflow.
KubeVirt isn't a replacement hypervisor, it's a bridge. It lets you run legacy VMs that can't be containerized yet alongside cloud native workloads under a single Kubernetes API, and migrate to containers at your own pace.
Path B migration
- 01
Build the cluster
Deploy a bare metal Kubernetes cluster.
- 02
Add the operators
Install Rook-Ceph for storage and KubeVirt for VM workloads.
- 03
Import
Import VMDKs into Ceph backed volumes.
- 04
Declare
Define VMs as version controlled, GitOps deployed manifests.
Ceph: the shared foundation
Whichever path you choose, Ceph is the storage layer. It's the only open source distributed storage system battle tested at scale for over a decade across both traditional VM and cloud native workloads.
- Block storage for VM disks and Kubernetes volumes.
- S3-compatible object storage for backups and media, with no AWS dependency.
- A POSIX compliant shared filesystem as an NFS replacement for legacy apps.
Ceph removes the proprietary SAN or NAS dependency most VMware environments carry: no more vendor locked storage controllers, no more per TB licensing, no more forklift upgrades.
The exit is mandatory. The architecture you land on afterward is entirely your choice.
Land on Onam Cloud
Keep reading
Start the conversation
Let's talk about whereyour infrastructureshould live.
Tell us about your workload, your compliance constraints, and where your users are, and we'll help you figure out the right shape.