If you’re running Kubernetes and still maintaining a separate hypervisor for VMs, we need to talk.
I see this constantly: teams build a solid Kubernetes platform, and then there’s a Proxmox cluster on the side for the “legacy” workloads. Two worlds. Two APIs. Two runbooks. Two escalation paths. And before you know it, you’re the person debugging both at 3 AM.
Here’s my thesis: If Kubernetes is your platform, KubeVirt is your hypervisor. Not “also.” Instead.
The Problem: Two Worlds
VMs aren’t going away. Legacy workloads, Windows servers, database appliances, compliance-bound systems, they’ll run as VMs for years to come. The question isn’t whether you need VMs. It’s how you manage them.
The traditional answer is a separate hypervisor layer: VMware, Proxmox, Hyper-V, each with its own API, authentication, networking model, and operational culture. The result? Bifurcated infrastructure. Two automation stacks. Two sets of runbooks. Two hiring profiles.
KubeVirt makes VMs Kubernetes resources. Defined by CRDs, managed by controllers, scheduled by the same scheduler, observable by the same Prometheus metrics, secured by the same RBAC. One platform. One API. One operational model.
This isn’t a convenience feature. It’s a force multiplier. Everything you’ve invested in Kubernetes (GitOps pipelines, observability stack, policy engines, developer self-service) extends automatically to VMs. You don’t rebuild these capabilities for a separate hypervisor. You inherit them.
Imperative vs Declarative (And Why It Matters)
Proxmox is imperative. You click a button or call an API, and the system executes it. No desired state. No reconciliation. If something fails halfway through, you have a VM in an inconsistent state and you debug manually.
Yes, Terraform exists. But the Proxmox Terraform provider (Telmate) is community-maintained. Over 1,500 total issues filed on GitHub (128 currently open). Constant breaks between versions. Cloud-init workflows that don’t work reliably. State drift after disk resize operations. This isn’t enterprise automation. It’s a workaround.
KubeVirt is declarative because it builds on Kubernetes. kubectl apply for Deployments? Same for VirtualMachines. ArgoCD syncs your container workloads? It syncs your VMs too. git revert for rollback? Exactly the same. GitOps isn’t bolted on. It’s the natural operating mode, and Kubermatic Virtualization supports declarative, GitOps-style YAML installation with self-healing on subsequent runs.
Multi-Tenancy: Permissions vs Policy
Proxmox has a permission system. Path-based. Roles. Users. And, here’s the problem, not much else. No NetworkPolicies. No admission controllers. No namespace isolation. Users on the same bridge can potentially sniff traffic from neighboring tenants. A 2026 DEV Community guide on Proxmox multi-tenancy puts it bluntly: “Understanding path permissions, inheritance, and pool semantics can be unexpectedly difficult for beginners. Good for controlled sharing, but weak for secure tenant environments.”
Multi-tenancy on Proxmox means gluing together RBAC, SDN zones, firewall rules, routing, and VPN manually. It’s an integration exercise, not a configuration exercise.
KubeVirt inherits the full Kubernetes security model: RBAC at the namespace level, NetworkPolicies (Calico/Cilium), Pod Security Standards, admission controllers (OPA/Gatekeeper, Kyverno), structured audit logging. And as of v1.8: Confidential Computing with Intel TDX, cryptographic attestation that VMs are running on trusted hardware. For regulated environments (finance, government), this isn’t a nice-to-have. It’s a hard requirement.
Scalability: 32 Nodes vs. Thousands
Proxmox clusters are practically limited to approximately 32 nodes. Proxmox’s own documentation says there’s “no explicit limit” but acknowledges that “the actual possible node count may be limited by the host and network performance.” Community experience and Proxmox’s own recommendation (PDM + multiple clusters) confirm: beyond 32 nodes, Corosync becomes a bottleneck. This isn’t a configuration issue. It’s an architectural ceiling.
Kubernetes scales to thousands of nodes. Google, Apple, Shopify prove this daily. KubeVirt inherits this scaling model. KubeVirt v1.8 was validated in SIG-Scale tests at 8,000 VMs, with linear memory growth in the control plane (virt-api: 140 MB to 170 MB, virt-controller: 65 MB to 1,400 MB). Node affinity, anti-affinity, taints/tolerations, topology spread constraints, priority classes, resource quotas, all available for VM scheduling. Proxmox has none of this.
Storage and Networking: The Full Ecosystem
Proxmox supports LVM, ZFS, Ceph, NFS, iSCSI. Solid choices for a standalone hypervisor. And that’s the complete list. Longhorn? Portworx? Cloud provider storage? CSI drivers? Not available.
KubeVirt uses the full Kubernetes CSI ecosystem. Any storage provider with a CSI driver works. Ceph via Rook (the same Ceph, managed declaratively). Longhorn. AWS EBS. Azure Disk. NetApp, Dell, Pure Storage. VM disks are PersistentVolumeClaims with StorageClasses, volume snapshots, and dynamic provisioning. And as of KubeVirt v1.8: CDI Incremental Backup with Changed Block Tracking (CBT), storage-agnostic incremental VM backups that drastically reduce backup windows and storage footprint.
Networking tells the same story. Proxmox offers Linux Bridge, VLAN, OVS. Functional basics. But no NetworkPolicies, no service mesh, no Ingress, no LoadBalancer, no Multus.
KubeVirt VMs are full participants in the Kubernetes network model. ClusterIPs, Services, Ingress, Cilium Hubble, NetworkPolicies, all present. A legacy web app running as a VM gets exposed via an Ingress controller with TLS termination and rate limiting. Exactly like a container service. KubeVirt v1.8 also promoted passt to core as a user-space networking plugin, rootless VM networking without privileged permissions.
The VMware Exit Argument
Since Broadcom acquired VMware, teams are looking for alternatives. Proxmox is the obvious choice for many: free, open source, “it does KVM too.” But Proxmox replaces VMware with an architecture that was state-of-the-art in 2010. Imperative, GUI-centric, limited scalability, weak multi-tenancy.
If you’re doing the VMware exit, do it right. KubeVirt + Kubernetes = declarative, API-first, GitOps-ready, scalable, secure multi-tenancy. This isn’t a sidestep. It’s an upgrade.
And the numbers back this up: according to the Spectro Cloud Survey 2025, 86% of Kubernetes adopters are aware of KubeVirt and 26% run it in production. Red Hat builds OpenShift Virtualization on it. NVIDIA uses it for GeForce NOW. Cloudflare runs it in core data centers. Swisscom operates their sovereign cloud with it. This isn’t a niche project anymore.
When Proxmox Makes Sense
In fairness, Proxmox is good software in the right context.
- No Kubernetes footprint. If you’re not running containers and not planning to, you don’t need Kubernetes for VMs.
- Integrated ZFS is a primary requirement. Proxmox’s ZFS integration is genuinely well-executed. For backup-focused teams managing their own storage, this matters.
- LXC meets your container needs. Proxmox’s LXC integration provides lightweight container isolation without Kubernetes overhead. For simple system container workloads, it’s sufficient.
- Budget is the primary constraint. Proxmox is free and open source. KubeVirt requires a Kubernetes cluster, which implies operational overhead.
- Scale is modest. Under 30 nodes, under 500 VMs, no multi-tenancy. Proxmox is enough.
The keyword in each case is “simple.” Proxmox works when requirements are simple and scale is modest. It struggles when requirements get complex, multiple teams share infrastructure, automation must be robust, and VMs and containers need to coexist under a unified operational model.
Kubermatic Virtualization
KubeVirt is a project, not a product. Running it in production means assembling a stack: Kubernetes on bare metal, an SDN for VM networking, load balancing, provisioning workflows, and operational tooling. That’s work.
Kubermatic Virtualization packages this into a suite: KubeVirt (VM runtime), KubeOVN (SDN/VPC networking with subnets, NAT, Elastic IPs), KubeOne (bare-metal provisioning and cluster lifecycle), KubeLB (load balancer for VM services), a declarative installer with TUI wizard and GitOps YAML, and a centralized management UI. No fork, upstream KubeVirt, plus the pieces you need to run it in production. Supported, as a single product.
Comparison
| Feature | Proxmox VE | KubeVirt |
|---|---|---|
| Architecture | Imperative, GUI-first | Declarative, API-first |
| Max cluster size | ~32 nodes | Thousands (Kubernetes limit) |
| GitOps | Community Terraform (1,500+ total issues, 128 open) | Native (kubectl apply, ArgoCD, Flux) |
| Multi-tenancy | Path-based permissions + manual integration | RBAC + Namespaces + NetworkPolicies + Admission Controllers |
| Storage ecosystem | 5 backends | CSI ecosystem (20+ drivers) |
| Networking | Linux Bridge, VLAN, OVS | CNI ecosystem (Calico, Cilium, Multus, Service Mesh) |
| Observability | API export, manual | Native (Prometheus, Grafana, Alertmanager) |
| Automation | REST API + custom scripts | CRDs + Operators + Helm + Kustomize |
| Compliance | No audit log, no admission controllers | Kubernetes Audit Log + OPA/Kyverno + TDX (v1.8) |
| Project status | Community, Proxmox GmbH | CNCF Incubating, 2,036+ contributors, 528+ organizations |
| Release cadence | Irregular | ~4 months (v1.5→v1.6→v1.7→v1.8 in 12 months) |
Conclusion
Proxmox vs. KubeVirt isn’t a feature checklist comparison. It’s a paradigm comparison. Imperative vs. declarative. Standalone vs. platform-integrated. GUI-centric vs. API-first.
If Kubernetes is your platform, adopt KubeVirt for virtualization. Don’t maintain two infrastructure paradigms. The cost of operating two worlds exceeds the cost of consolidating onto one.
And if you’re thinking “this is all theory”: according to the Spectro Cloud Survey 2025, 26% of Kubernetes users run KubeVirt in production. Two years ago, that was single digits. 2,036 contributors from 528 organizations are building it. The train is moving.
The detailed version with all sources, deep architecture comparisons, and compliance analysis is available as a whitepaper: Proxmox vs KubeVirt Whitepaper.
