KubeVirt or Proxmox? An Architectural Decision Guide for 2026

1. Executive Summary

Figure 1: The bifurcation problem (left) versus a unified Kubernetes-native platform (right).

Organizations running Kubernetes face a fundamental infrastructure decision: how to manage virtual machines alongside containers. Two architectures diverge. Proxmox VE offers an approachable, standalone hypervisor with integrated ZFS and LXC. KubeVirt brings VMs into Kubernetes itself, treating them as first-class citizens of the same declarative, API-driven ecosystem that already runs your containers.

This whitepaper argues that for any organization with an existing Kubernetes investment, KubeVirt is the strategically superior choice. The gap is not marginal—it is architectural. Proxmox operates on an imperative, GUI-centric model with limited extensibility and weak multi-tenancy. KubeVirt inherits the full operational model of Kubernetes: declarative state, reconciliation loops, GitOps, RBAC, CSI storage, CNI networking, and an ecosystem of operators, Helm charts, and monitoring tooling that no standalone hypervisor can match.

The argument is not that Proxmox is bad software. It is that Proxmox lives in a different world—one that becomes increasingly expensive to maintain as your Kubernetes footprint grows. Bridging two operational paradigms—imperative hypervisor management and declarative cluster management—creates friction that compounds with scale. KubeVirt eliminates that bridge entirely.

For organizations looking for a turnkey implementation, Kubermatic Virtualization packages KubeVirt, KubeOVN, and KubeOne into a supported hypervisor suite with a centralized management UI, declarative installer, and enterprise-grade networking and storage—covered in detail in Section 13.

Key takeaway: If Kubernetes is your platform, KubeVirt is your hypervisor.

Market context: Since Broadcom's acquisition of VMware, the virtualization landscape has been reshaped. A 2025 Spectro Cloud survey of Kubernetes adopters found that 86% are aware of KubeVirt and 26% are running it in production ^[1]. Proxmox has gained adoption in the SMB and homelab space, but its architectural limitations make it a dead end for organizations investing in cloud-native infrastructure.

2. The Case for Kubernetes-Native Virtualization

Virtual machines are not going away. Legacy workloads, Windows servers, database appliances, and compliance-bound systems will run as VMs for years to come. The question is not whether you need VMs, but how you manage them.

The traditional answer is a separate hypervisor layer: VMware, Proxmox, Hyper-V—each with its own API, its own authentication, its own networking model, its own operational culture. This creates a bifurcated infrastructure. Your containers live in one world, your VMs in another. Two sets of automation. Two sets of runbooks. Two escalation paths. Two hiring profiles.

Kubernetes-native virtualization via KubeVirt resolves this bifurcation. A KubeVirt virtual machine is a Kubernetes resource, defined by a CRD, managed by a controller, scheduled by the same scheduler, observable by the same Prometheus, secured by the same RBAC. There is no second world. There is one platform, one API, one operational model.

This is not merely a convenience. It is a force multiplier. Every investment you have made in Kubernetes—your GitOps pipelines, your observability stack, your policy engines, your developer self-service portals—extends automatically to VMs. You do not rebuild these capabilities for a separate hypervisor. You inherit them.

3. Architecture Comparison: Proxmox vs KubeVirt

3.1 Proxmox VE Architecture

Proxmox VE is a monolithic hypervisor distribution built on Debian, integrating KVM for virtualization and LXC for containers. Management flows through a custom web GUI or the pvesh CLI shell, backed by a REST API. Cluster coordination uses Corosync for quorum and Ceph (via pveceph) or ZFS replication for shared storage. Configuration state is stored in pmxcfs, a custom database layer built on Corosync.

Figure 2: Proxmox VE monolithic architecture — self-contained, imperative, limited integration points.

The architecture is self-contained. Integration points are limited to the REST API and, to a lesser extent, the Terraform Proxmox provider. There is no concept of controllers, reconciliation loops, or declarative state. Changes are made imperatively and persist until changed again.

Critical limitation: Proxmox's cluster architecture depends on Corosync synchronous communication and pmxcfs, which creates hard scaling limits. Proxmox's own documentation states there is "no explicit limit" for the number of nodes in a cluster, but acknowledges that "the actual possible node count may be limited by the host and network performance" ^[2].
Community consensus and practical experience put the reliable limit around 32 nodes. Beyond that, Corosync latency and quorum management degrade ^[3]. This is not a configuration tweak; it is an architectural ceiling.

3.2 KubeVirt Architecture

KubeVirt extends Kubernetes with CRDs for VirtualMachine and VirtualMachineInstance. The KubeVirt controller runs as a standard Kubernetes operator. Each VM is backed by a Pod running libvirt, scheduled by the Kubernetes scheduler. The Containerized Data Importer (CDI) handles VM image imports. Networking, storage, and observability all leverage existing Kubernetes infrastructure.

Figure 3: KubeVirt composable architecture — every component replaceable, reconciled, observable.

The architecture is composable. Every component can be replaced, upgraded, or extended independently. The system converges toward desired state continuously through reconciliation. Kubernetes itself has been demonstrated running thousands of nodes in production at organizations like Google, Apple, and Shopify—KubeVirt inherits this scalability model. KubeVirt v1.8's SIG Scale testing validated the control plane at 8,000 VMs, with linear memory growth: virt-api memory increased from 140 MB to 170 MB, and virt-controller from 65 MB to 1,400 MB across that range ^[4].

4. Operational Model: Imperative vs Declarative

Figure 4: Imperative (left) versus declarative (right) operational models. KubeVirt continuously reconciles desired state; Proxmox requires manual intervention for every change and every failure.

4.1 Proxmox: Imperative by Design

Proxmox management is action-oriented. You click a button or run a command, and the system executes it. There is no desired state. There is only current state, modified by actions. If an action fails partially, you diagnose and remediate manually.

Consider a VM provisioning workflow:

1. Administrator clicks "Create VM" in GUI or calls qm create via API
2. VM is created
3. Administrator configures network, storage, boot order separately
4. If step 3 fails, VM exists in an incomplete state
5. No automated remediation

This model is familiar and intuitive for small teams managing a handful of hosts. It breaks down at scale. When you manage hundreds of VMs across multiple clusters, the lack of desired-state tracking means you cannot answer a simple question: "Does this infrastructure match our intended configuration?" You can only inspect current state and hope it is correct.

Terraform partially addresses this by providing declarative syntax, but the Proxmox Terraform provider is a community-maintained effort (Telmate/terraform-provider-proxmox) that wraps the imperative API. It does not benefit from the same first-class integration that the Kubernetes Terraform provider enjoys. State drift detection is fragile, and the provider frequently lags behind Proxmox API changes. As of June 2026, the provider has had over 1,500 total issues filed on GitHub (with ~128 currently open), with recurring reports of crashes during VM creation, state inconsistency after disk resize operations, and broken cloud-init workflows ^[5].

4.2 KubeVirt: Declarative by Nature

KubeVirt inherits Kubernetes' declarative model. A VirtualMachine resource describes desired state. The KubeVirt controller continuously reconciles current state against desired state. If a VM is supposed to be running and is not, the controller fixes it. If a VM's configuration drifts, the next reconciliation corrects it.

This is not a convenience wrapper. This is how the system works at its core. The same kubectl apply that manages Deployments manages VirtualMachines. The same ArgoCD Application that syncs your container workloads syncs your VM workloads. The same kubectl diff that previews changes to a ConfigMap previews changes to a VM's CPU allocation.

GitOps is not bolted on. It is the natural operating mode. Your VM definitions live in Git. Changes go through code review. ArgoCD or Flux applies them automatically. Rollback is git revert. Audit trail is git log. There is no separate change management process for VMs. The KubeVirt user guide explicitly documents GitOps workflows, and Kubermatic Virtualization supports declarative, GitOps-style YAML installation with self-healing on subsequent runs ^[6].

5. Day-2 Operations at Scale

5.1 Scheduling and Lifecycle

Proxmox offers basic cluster features: HA groups, live migration via shared storage, and a simple priority system for HA failover. These work for small clusters. They are not comparable to Kubernetes scheduling.

Kubernetes scheduling for KubeVirt VMs includes:

• Node affinity and anti-affinity: Pin database VMs to nodes with NVMe, spread web server VMs across racks
• Taints and tolerations: Dedicate nodes to VM workloads, exclude VMs from container-only nodes
• Pod topology spread constraints: Ensure VMs are distributed across failure domains
• Node draining: kubectl drain gracefully migrates VMs off a node for maintenance, respecting LiveMigrate eviction strategies
• Resource quotas: Limit VM resource consumption per namespace, preventing any team from starving others
• Priority classes: When resources are scarce, critical VMs preempt less important ones according to policy

Proxmox has none of these. VM placement is manual or based on simple HA group assignments. Node maintenance requires manual migration. There is no priority-based preemption. There is no namespace-based quota enforcement. On the Proxmox forums, users regularly ask how to enforce per-pool resource quotas—the consistent answer is that Proxmox lacks native quota enforcement, and administrators must resort to manual discipline or external scripting ^[7].

5.2 Migration

Proxmox supports live migration with shared storage (Ceph or NFS). It is functional but limited: no affinity-aware placement after migration, no automatic rebalancing, and no integration with a broader scheduling policy.

KubeVirt supports live migration as a first-class operation triggered by Kubernetes itself. When a node needs draining for kernel updates, the Kubernetes eviction controller signals KubeVirt, which migrates VMs according to the same scheduling policies that govern placement. No manual intervention. No separate runbook. The same kubectl drain you use for Pods works for VMs.

In KubeVirt v1.6 (June 2025) and v1.7 (November 2025), live migration has been further hardened with dedicated migration networks, enabling cross-cluster migration using EVPN and OpenPERouter for complete separation from application networking. This is production-grade workload mobility that Proxmox cannot match—Proxmox's live migration is confined to a single cluster with shared storage.

5.3 Observability

Proxmox monitoring is external. You can export metrics via Proxmox's API to a Prometheus instance, but this is an ad-hoc integration. There is no native service discovery, no standard dashboards, no alerting rules baked into the platform.

KubeVirt inherits the Kubernetes observability stack. The kube-prometheus-stack provides Prometheus, Grafana, and Alertmanager out of the box. KubeVirt exposes metrics via the standard Kubernetes /metrics endpoint: VMI creation/deletion rates, migration status, CPU and memory utilization per VMI, storage and network performance. Service discovery is automatic. Dashboards are community-maintained and production-ready. Alerting rules follow Kubernetes conventions.

Your existing Grafana dashboards for Kubernetes extend to VMs. Your existing PagerDuty integration catches VMI crashes. There is no separate monitoring stack to build and maintain.

6. Security and Multi-Tenancy

Figure 5: Proxmox offers path-based permissions (left); KubeVirt inherits the full Kubernetes security framework — RBAC, namespaces, NetworkPolicy, quotas, admission control, and audit logging (right).

6.1 Proxmox: Permissions, Not Policy

Proxmox uses a custom permission system built on paths, roles, and users. You can assign a user permissions on a VM, on a pool, or on a node. The model is coarse. There are no network policies, no pod security standards, no namespace isolation. Users with access to a VM on the same bridge can potentially access other VMs' traffic. There is no built-in tenant isolation beyond VLAN tagging.

Proxmox introduced a Software-Defined Network (SDN) feature in recent versions, enabling VNet isolation with VLAN and QinQ zones. However, a 2026 multi-tenant guide on DEV Community acknowledges the reality: "Understanding path permissions, inheritance, and pool semantics can be unexpectedly difficult for beginners. Good for controlled sharing, but weak for secure tenant environments." ^[8] Achieving real multi-tenancy on Proxmox requires gluing together RBAC, SDN zones, firewall rules, routing, VPN entry points, and user permissions manually. It is an exercise in integration, not configuration.

On the Proxmox forums, users attempting per-pool resource quotas for CPU, RAM, and disk consistently find that the platform lacks native enforcement. One thread from February 2026 explicitly states: "Real multi-tenancy also needs to consider anonymous neighbor tenants, which will be a nasty setup with multiple authentication realms." ^[9]

Concrete attack vectors in Proxmox multi-tenancy:

• Lateral network movement: Without CNI-level NetworkPolicies, VMs on the same Linux bridge can ARP-spoof or sniff traffic from neighboring tenants.
• Privilege escalation via pool misconfiguration: Proxmox path-based permissions inherit hierarchically. A misconfigured Pool.Admin role grants access far beyond the intended VMs.
• No admission validation: There is no equivalent of Kubernetes admission controllers. Any user with VM creation rights can create a VM with any configuration—no policy enforcement, no resource limit validation.
• Audit trail gaps: Proxmox logs actions to syslog, but there is no structured audit log equivalent to Kubernetes audit logging. Forensic investigation of unauthorized changes requires manual log correlation.

6.2 KubeVirt: Kubernetes-Grade Security

KubeVirt inherits the full Kubernetes security model:

• RBAC: Fine-grained Role-Based Access Control at the namespace and resource level. Team A gets VirtualMachine CRUD in namespace team-a. Team B gets the same in namespace team-b. Neither can see the other's resources.
• Namespaces: Hard logical boundaries for resource ownership, quotas, and network policy.
• NetworkPolicies: Calico or Cilium enforce L3/L4 isolation between namespaces. Team A's VMs cannot reach Team B's VMs unless you explicitly allow it. This is enforced in the data plane, not just the control plane.
• Pod Security Standards: KubeVirt runs VMs in Pods, subject to the same security constraints. You can enforce restricted, baseline, or privileged profiles per namespace.
• Admission controllers: OPA/Gatekeeper or Kyverno can validate VM specifications before they are created. No VMs without approved labels. No VMs exceeding resource limits. No VMs mounting sensitive volumes.
• Audit logging: Kubernetes audit logs record every API call, including VM creation, modification, and deletion, with user identity and timestamps.
• Confidential Computing (KubeVirt v1.8+): Intel TDX attestation support enables VMs to cryptographically certify they are running on confidential hardware—critical for regulated workloads in finance and government ^[4].

The difference is not incremental. Proxmox offers a permission system. Kubernetes offers a security framework.

7. Storage and Networking Ecosystem

7.1 Storage

Proxmox supports LVM, ZFS, Ceph (via pveceph), NFS, and iSCSI. These are solid choices for a standalone hypervisor. The limitation is that this is the complete list. If your organization standardizes on a cloud provider's block storage, on Longhorn, on Portworx, or on any CSI-compatible storage system, Proxmox cannot use it. You run whatever Proxmox supports, or you build and maintain custom integration yourself.

KubeVirt uses the Kubernetes CSI (Container Storage Interface) ecosystem. Any storage provider with a CSI driver works. This includes:

• Ceph via Rook, the same Ceph Proxmox uses, but managed declaratively via Kubernetes
• Longhorn, purpose-built for Kubernetes-native distributed storage
• Cloud provider storage: AWS EBS, Azure Disk, GCE Persistent Disk via their CSI drivers
• NetApp, Dell, Pure Storage, and every enterprise storage vendor with a CSI driver
• Local PVs, hostPath volumes, and any future storage backend

VM disks are PersistentVolumeClaims. They benefit from StorageClasses, volume snapshots, volume cloning, and dynamic provisioning. CDI imports VM images from HTTP, S3, or container registries into PVCs, making image distribution as straightforward as container image pulls.

In KubeVirt v1.8 (March 2026), CDI adds Incremental Backup with Changed Block Tracking (CBT), using QEMU and libvirt backup capabilities to produce storage-agnostic incremental VM backups. This enables faster backups and significant reduction in storage footprint—capabilities that Proxmox's backup tooling (vzdump) cannot match at this granularity ^[4].

7.2 Networking

Proxmox provides Linux Bridge, VLAN, and Open vSwitch. These are standard hypervisor networking primitives. They work for basic VM connectivity. They do not provide:

• Network policies (L3/L4 firewalling between VMs)
• Service mesh (mTLS, traffic management, observability for VM-to-VM communication)
• eBPF-based observability (packet-level visibility without packet capture)
• Load balancing (Proxmox has no concept of a Service or LoadBalancer)
• Ingress (HTTP routing, TLS termination for VM-hosted web services)
• Multus or CNI chaining (multiple network interfaces per VM with different CNI plugins)

KubeVirt VMs are full participants in the Kubernetes network model. They get ClusterIPs, they respond to Services, they sit behind Ingress controllers, they are observed by Cilium's Hubble, and they are protected by NetworkPolicies. A VM hosting a legacy web application can be exposed via an Ingress controller with TLS termination, rate limiting, and WAF rules—exactly as if it were a container-based service.

KubeVirt v1.8 promoted the passt user-space network connectivity plugin from experimental to core, enabling rootless VM networking. The same release decoupled Network Attachment Definition (NAD) references from the virt-controller, reducing API calls and removing permissions previously required for VM activation at scale ^[4].

For organizations seeking a turnkey networking stack, Kubermatic Virtualization integrates KubeOVN as the default SDN, providing flat L2/L3 networking, VPC isolation, subnets, NAT gateways, Elastic IPs, and routing tables—all expressed as Kubernetes CRDs and manageable from the same control plane.

8. Extensibility and Developer Experience

8.1 Proxmox: Closed Extensibility

Proxmox is extensible in limited ways: custom scripts hooked into VM lifecycle events, the REST API for external automation, and the Perl-based codebase for the truly adventurous. There is no plugin system, no operator pattern, no CRD mechanism. You cannot define a new resource type. You cannot write a controller that reacts to VM events. You cannot package a VM template as a Helm chart and distribute it through a chart repository.

The developer experience for automation is: read the API docs, write a script, run it, handle errors. This works. It does not scale to self-service platforms.

As a 2025 technical analysis on CloudInfra.blog documented: "Proxmox lacks comprehensive, enterprise-ready APIs for dynamic node provisioning or automated expansion. Most of these operations require manual CLI interaction or custom scripts, limiting automation and agility." ^[10] The same analysis notes that Proxmox has no first-party Terraform or Ansible modules—relying entirely on community-maintained providers that are "often outdated, poorly documented, and break between Proxmox versions." ^[10]

8.2 KubeVirt: Extensible by Design

KubeVirt benefits from Kubernetes' extensibility model:

• CRDs: Define custom resources that reference VMs. A DatabaseCluster CRD can encapsulate VM specs, ConfigMaps, Services, and NetworkPolicies into a single composable unit.
• Operators: Write controllers that manage VM lifecycles. An operator can provision a VM, configure it via cloud-init, register it in a load balancer, and run health checks—all as a single automated workflow.
• Helm and Kustomize: Package VM definitions into Helm charts. Distribute them through artifact repositories. Override values per environment. This is how infrastructure becomes shareable and versioned.
• Webhooks: Admission webhooks validate and mutate VM specs. Enforce organizational standards automatically.
• Custom controllers: Use Kubernetes informers and client-go to build custom automation that reacts to VM creation, migration, and deletion.
• KubeVirt Enhancement Proposals (VEPs): Since v1.6, the project has formalized its enhancement process with VEPs (analogous to Kubernetes KEPS), making it transparent and community-driven ^[4].

For platform teams, this is transformative. You are not scripting against an API. You are building abstractions. A developer requests a VM by creating a custom resource. Your operator provisions it. Your policies validate it. Your GitOps pipeline deploys it. The developer never touches the hypervisor, and the platform team never writes another provisioning script.

9. Project Velocity and Ecosystem Maturity

9.1 KubeVirt: CNCF Incubating Project with Accelerating Velocity

KubeVirt is a CNCF Incubating project (promoted April 2022) with substantial and measurable momentum. The following table summarizes current ecosystem metrics as reported by the CNCF:

The release cadence is aggressive and disciplined: v1.5 (March 2025), v1.6 (July 2025), v1.7 (November 2025), v1.8 (March 2026). Each release aligns with a Kubernetes minor version (v1.8 aligns with Kubernetes v1.35). The project has formalized its governance with VEPs and an expanding set of Special Interest Groups (SIGs) covering compute, networking, storage, and scale.

The breadth of this ecosystem matters. With over 500 contributing organizations and a regular release cadence aligned to Kubernetes, KubeVirt benefits from diverse investment and is not dependent on any single vendor's roadmap.

Notable enterprise adopters validate KubeVirt's production readiness across industries:

9.2 Proxmox: Small Core Team, Slower Enterprise Evolution

Proxmox is developed by Proxmox Server Solutions GmbH, an Austrian company with a small core development team. While the community forum is active (and valuable for homelab users), the pace of enterprise-driven feature development is limited. Proxmox VE 9.0 was released in August 2025, based on Debian 13 (Trixie). Proxmox VE 8.x reaches EOL in August 2026.

Key observations:

• No CNCF or foundation backing. Proxmox is a single-vendor project with no independent governance model.
• Slow multi-tenancy evolution. SDN was introduced only recently and still requires manual assembly of RBAC, firewall rules, and routing for real tenant isolation.
• Enterprise support is limited. The Community tier (€120/CPU socket/year) provides access to the enterprise repository but no support tickets or SLA. The Premium tier's response times and coverage do not match established enterprise virtualization vendors ^[13].
• No formal compliance certifications. Proxmox does not hold ISO 27001, SOC 2, or BSI IT-Grundschutz certifications. For German and EU enterprises subject to NIS2 or BSI requirements, this is a gap that cannot be filled by a community forum.

10. Cost Comparison: Total Cost of Ownership

Figure 6: Relative TCO comparison. Proxmox (dark) versus KubeVirt (light). While both are free to license, operational costs diverge sharply once you account for automation, multi-tenancy, monitoring, and scaling overhead.

A common argument for Proxmox is that it is "free." This is true in the narrowest sense: the software itself costs nothing to download. But TCO is not license cost.

10.1 Proxmox TCO

10.2 KubeVirt TCO

Bottom line: Proxmox's "free" license is offset by higher operational costs, staffing overhead for dual paradigms, and hard scaling limits. For organizations already running Kubernetes, adding Proxmox creates a cost center that KubeVirt eliminates entirely.

11. Compliance and Certification

For European enterprises, particularly those subject to BSI IT-Grundschutz, ISO 27001, or NIS2 requirements, the compliance properties of your infrastructure platform are not optional—they are regulatory requirements.

Proxmox: No Compliance Foundation

Proxmox has no formal compliance certifications. There is no ISO 27001 certification for the Proxmox platform. No SOC 2 report. No BSI IT-Grundschutz profile. No CIS benchmark for Proxmox hardening. Organizations running Proxmox in regulated environments must build their own compliance evidence from scratch.

The absence of structured audit logging (beyond syslog), admission control, and policy enforcement makes it difficult to demonstrate the technical controls required by ISO 27001 Annex A or BSI IT-Grundschutz. Proxmox's permission model does not map cleanly to the principle of least privilege as defined by these frameworks.

KubeVirt: Built on a Compliant Platform

Kubernetes has a mature compliance ecosystem:

• CIS Kubernetes Benchmark provides detailed hardening guidance.
• Red Hat OpenShift (which includes OpenShift Virtualization based on KubeVirt) holds ISO 27001, SOC 2, and FIPS 140-2 certifications.
• Kubermatic KKP is designed with compliance in mind, supporting BSI IT-Grundschutz and ISO 27001 control mappings.
• OPA/Gatekeeper and Kyverno enforce compliance policies at admission time: no privileged containers, no VMs without approved labels, mandatory resource limits.
• Kubernetes audit logging provides structured, queryable records of every API call—exactly what auditors require.

For German and EU enterprises, KubeVirt on a compliant Kubernetes platform means your VM infrastructure inherits the compliance properties you have already invested in for your container infrastructure. Proxmox requires you to build a separate compliance story from scratch.

12. Advanced Capabilities: GPU, SR-IOV, and AI/ML Workloads

12.1 KubeVirt: First-Class Hardware Acceleration

KubeVirt has invested heavily in hardware acceleration support, driven by the AI/ML workload explosion:

• GPU Passthrough: Fully supported for NVIDIA, AMD, and Intel GPUs. The NVIDIA GPU Operator integrates directly with KubeVirt, enabling GPU resource discovery, driver installation, and passthrough configuration through Kubernetes CRDs. No manual PCI binding scripts.
• NVIDIA vGPU and MIG: KubeVirt supports NVIDIA vGPU partitioning and Multi-Instance GPU (MIG) for fine-grained GPU sharing across VMs.
• SR-IOV: KubeVirt integrates with the Kubernetes SR-IOV Network Operator for near-native network performance. Virtual Functions can be assigned directly to VMs, bypassing the hypervisor networking stack.
• Intel Graphics SR-IOV: Intel's kubevirt-gfx-sriov project enables Graphics SR-IOV for GPU sharing in virtualized environments.
• PCIe NUMA topology awareness (v1.8): KubeVirt v1.8 introduced PCIe NUMA topology awareness, allowing AI and HPC workloads to achieve near-native performance by ensuring proper NUMA alignment of CPU, memory, and PCIe devices ^[4].
• Confidential Computing (v1.8): Intel TDX attestation enables VMs to cryptographically prove they are running on confidential hardware—a critical capability for regulated AI workloads processing sensitive data ^[4].

12.2 Proxmox: Basic GPU Support, No AI/ML Integration

Proxmox supports GPU passthrough via PCI passthrough configuration, but it is a manual process: identify the PCI device, add it to the VM config, ensure VFIO driver binding on the host. There is no operator, no CRD, no dynamic resource discovery. NVIDIA vGPU support was added in Proxmox VE 9 (August 2025) and requires GRID version 18.3+ driver compatibility.

There is no equivalent of the Kubernetes device plugin model. There is no SR-IOV Network Operator. There is no MIG support. There is no NUMA topology awareness in VM scheduling. There is no confidential computing integration.

For organizations running AI/ML workloads—which increasingly require GPU-accelerated VMs with sophisticated scheduling—Proxmox offers the raw capability of PCI passthrough without any of the orchestration that makes it production-viable at scale.

13. Kubermatic Virtualization: The Complete KubeVirt-Based Hypervisor Suite

The preceding sections have established KubeVirt's architectural advantages as a Kubernetes-native virtualization runtime. But KubeVirt is a project, not a product. Running KubeVirt in production requires assembling a stack: a Kubernetes cluster on bare metal, an SDN for VM networking, a load balancer for Service exposure, a provisioning workflow for the underlying infrastructure, and operational tooling for day-2 management.

Kubermatic Virtualization is the product that delivers this stack as a cohesive, supported whole. It is not a UI layer on top of KubeVirt—it is a complete hypervisor suite, built on open-source components, with each layer purposefully integrated.

Architecture

Figure 7: The Kubermatic Virtualization stack — from bare-metal provisioning through VM runtime to centralized management, each layer built on Kubernetes-native components.

KubeVirt — VM Runtime

KubeVirt is the virtualization engine at the core of Kubermatic Virtualization. It provides:

• CRDs for VirtualMachine and VirtualMachineInstance, making VMs first-class Kubernetes objects managed via kubectl, Helm, or ArgoCD.
• libvirt-based Pods for each VM, scheduled by the Kubernetes scheduler with full affinity, taint, and topology support.
• Containerized Data Importer (CDI) for importing VM images from HTTP, S3, container registries, or PVC clones, with Incremental Backup and Changed Block Tracking in v1.8.
• Live Migration as a first-class operation, integrated with Kubernetes node draining and eviction.

Kubermatic Virtualization ships the upstream KubeVirt project without forking, ensuring full compatibility with the CNCF ecosystem and all future KubeVirt releases.

KubeOVN — SDN/VPC Networking

KubeOVN (a CNCF Sandbox project) provides the software-defined network layer:

• Flat L2/L3 networking for all workloads (VMs and containers share the same network fabric).
• VPC isolation with subnets, NAT gateways, Elastic IPs, and routing tables—all expressed as Kubernetes CRDs.
• NetworkPolicy enforcement at the VPC and subnet level, enabling true multi-tenant isolation.
• EVPN and cross-cluster connectivity for multi-region deployments.

This is not an optional add-on. In Kubermatic Virtualization, KubeOVN is the default and recommended CNI, pre-configured during installation. VMs get IP addresses from the same subnet fabric as containers, without manual bridge configuration.

KubeOne — Bare-Metal Provisioning and Lifecycle

KubeOne handles the infrastructure foundation:

• Automated bare-metal Kubernetes cluster provisioning, turning a set of servers into a production-ready KubeVirt host cluster.
• Full lifecycle management: upgrades, certificate rotation, and node scaling via declarative configuration.
• Air-gapped support: every component ships as an OCI artifact, and the installer handles offline image mirroring.
• Tenant cluster provisioning: KubeOne also creates tenant Kubernetes clusters inside KubeVirt VMs, giving teams their own isolated K8s environments on shared infrastructure.

KubeLB — Native Load Balancing

KubeLB provides the LoadBalancer service integration that bare-metal Kubernetes environments typically lack:

• Native LoadBalancer Service type for VM workloads, equivalent to cloud-provider load balancers.
• Eliminates the need for MetalLB or external load balancer configuration in most deployments.
• Integrated with KubeOVN for seamless traffic routing from external clients to VM-hosted services.

Centralized Management UI

The Kubermatic Virtualization UI is the operational console—a single pane of glass for:

• VM lifecycle: create, start, stop, migrate, delete VMs with point-and-click or CLI.
• Networking: manage VPCs, subnets, NAT gateways, and Elastic IPs.
• Storage: provision and manage PVCs for VM disks, view storage class usage.
• Cluster management: monitor and manage both the infrastructure cluster and tenant clusters.
• Monitoring: integrated dashboards for VM health, resource utilization, and events.

The UI abstracts the power of KubeVirt, KubeOVN, and KubeOne into one intuitive interface, making it accessible to administrators who may not be Kubernetes experts ^[14].

Declarative Installer

Kubermatic Virtualization includes a purpose-built installer with two modes:

• Interactive TUI wizard: guided setup for initial deployment, with preconfigured storage and load balancing defaults.
• GitOps YAML: declarative configuration that can be version-controlled in Git. Subsequent runs are self-healing: if configuration drifts, re-running kubermatic-virtualization apply reconciles the cluster back to desired state.

Both modes support full air-gapped deployment, with all container images available as OCI artifacts for offline registries.

HA and Live Migration

High availability in Kubermatic Virtualization is not an add-on—it is inherent in the architecture:

• Kubernetes reconciliation: if a VM crashes, the KubeVirt controller automatically restarts it on a healthy node.
• Live migration: move running VMs between physical hosts with zero downtime, enabling seamless hardware maintenance.
• Node draining: kubectl drain triggers live migration of all VMs on the target node, respecting scheduling policies.
• Control plane HA: the Kubernetes control plane runs in HA mode with etcd quorum, ensuring the management layer survives node failures.

Data Protection

• CSI-integrated backup: VM disks are PersistentVolumeClaims, fully compatible with any CSI driver's snapshot and backup capabilities.
• CDI Incremental Backup with CBT (KubeVirt v1.8): storage-agnostic incremental VM backups using QEMU/libvirt Changed Block Tracking, reducing backup windows and storage footprint.
• Third-party backup integration: Kubermatic's partner ecosystem includes Trilio and Portworx for enterprise-grade backup and disaster recovery, accessible via Kubernetes-native APIs.

Security

• RBAC: fine-grained role-based access control at namespace and resource levels.
• NetworkPolicies: enforced by KubeOVN at the VPC and subnet level, providing L3/L4 isolation between tenants.
• Admission controllers: OPA/Gatekeeper or Kyverno integration for policy enforcement before VM creation.
• Audit logging: structured Kubernetes audit logs for every API call.
• Zero Trust: no user, device, or workload is inherently trusted—continuous authentication and authorization before access is granted ^[14].

Partner Ecosystem

Kubermatic Virtualization integrates with established enterprise vendors:

• Storage: NetApp, Dell, Pure Storage, and any CSI-compatible storage provider.
• Backup and DR: Portworx, Trilio, and other Kubernetes-native backup solutions.
• Security: Kyverno for policy enforcement, OPA/Gatekeeper for admission control.

Customer Validation

Swisscom's deployment runs an entirely open-source stack—KKP, KubeVirt, and Kube-OVN on bare metal—to deliver a CNCF-certified Kubernetes service with full data sovereignty within Switzerland ^[15].

14. Conclusion and Recommendation

The Proxmox versus KubeVirt comparison is not a feature checklist. It is a paradigm comparison. Proxmox represents the traditional hypervisor paradigm: imperative, standalone, GUI-centric. KubeVirt represents the Kubernetes-native paradigm: declarative, composable, API-centric.

For organizations with an existing Kubernetes investment, the strategic choice is clear. KubeVirt eliminates operational bifurcation, inherits enterprise-grade security and multi-tenancy, leverages the full CSI and CNI ecosystems, enables GitOps for VMs, and provides extensibility through CRDs, operators, and the broader Kubernetes ecosystem. Proxmox, for all its accessibility, cannot match these capabilities because they require architectural foundations that Proxmox does not have and cannot retrofit.

The data supports this. 26% of Kubernetes adopters are already running KubeVirt in production ^[1]. 2,036 contributors from 528 organizations are building KubeVirt ^[11]. CNCF incubation validates the project's governance, community health, and production readiness. The release cadence (v1.5 → v1.6 → v1.7 → v1.8 in 12 months) demonstrates sustained velocity. KubeVirt v1.8's Hypervisor Abstraction Layer, confidential computing support, and 8,000-VM scale validation demonstrate production maturity ^[4].

The recommendation:

If Kubernetes is your platform, adopt KubeVirt for virtualization. Do not maintain a separate hypervisor for VMs. The cost of operating two infrastructure paradigms exceeds the cost of consolidating onto one.

For organizations evaluating this transition, Kubermatic Virtualization delivers the complete stack: KubeVirt for VM runtime, KubeOVN for SDN/VPC networking, KubeOne for bare-metal provisioning, KubeLB for load balancing, a centralized management UI, and a declarative installer—all supported as a single product. It is the turnkey path from "we want Kubernetes-native VMs" to "we have a production hypervisor suite."

15. When Proxmox Makes Sense

Fairness requires acknowledging where Proxmox excels. Proxmox is an excellent choice when:

• The organization has no Kubernetes investment. If you are a small business, a homelab, or a team that runs no containers and plans no containers, Proxmox gives you capable virtualization with a low learning curve.
• Integrated ZFS is a primary requirement. Proxmox's ZFS integration is genuinely well-executed. Snapshots, send/receive, and compression are first-class features. For backup-obsessed teams managing their own storage, this matters.
• LXC containers meet your container needs. Proxmox's LXC integration provides lightweight container isolation without Kubernetes overhead. For simple system container workloads, this is sufficient.
• Budget is the primary constraint. Proxmox is free and open source. The total cost of entry is hardware. KubeVirt requires a Kubernetes cluster, which implies operational overhead and potentially paid platform licenses.
• Scale is modest (<30 nodes, <500 VMs). Proxmox's limitations become visible at scale. Below this threshold, they may not matter.

The key word in each of these cases is "simple." Proxmox excels when requirements are simple and scale is modest. It struggles when requirements become complex, when multiple teams share infrastructure, when automation must be robust, and when VMs and containers must coexist under a unified operational model.

Sources

1. Spectro Cloud, "KubeVirt in the Real World," December 2025.
2. Proxmox VE Wiki, "Cluster Manager."
3. Proxmox Forum, "Max Cluster Size."
4. KubeVirt Community, "Announcing the Release of KubeVirt v1.8," March 25, 2026.
5. Telmate/terraform-provider-proxmox, GitHub Issues.
6. Kubermatic, "What Is KubeVirt, and How Does It Fit Into Kubermatic Virtualization?" April 30, 2026.
7. Proxmox Forum, "How Do You Enforce Per-Pool Tenant Resource Quotas?"
8. DEV Community, "Proxmox Multi-Tenant Guide: RBAC vs SDN vs MSL Setup 2026," March 2026.
9. Proxmox Forum, "Per-Pool Resource Quotas for CPU, RAM, Disk," February 2026.
10. CloudInfra.blog, "Why Proxmox Is Not Enterprise-Ready: A Technical Breakdown," November 2025.
11. CNCF, "KubeVirt Project Page."
12. KubeVirt Releases.
13. Petronella Tech, "Is Proxmox Free? Enterprise Licensing Explained 2026," May 2026.
14. Kubermatic, "Kubermatic Virtualization Product Page."
15. Kubermatic, "Swisscom's Journey from Vendor Lock-In to Cloud Native Infrastructure Platform."
16. InfoQ, "KubeVirt v1.8 Brings Multi-Hypervisor Support and Confidential Computing to Kubernetes," March 2026.
17. "Dedicated Migration Networks for Cross-Cluster Live Migration," KubeVirt.io, October 2025.
18. "Reaching Escape Velocity for OpenShift Virtualization," Red Hat, April 2026.
19. NVIDIA GPU Operator with KubeVirt.
20. Kubermatic, "The Wait Is Over: Kubermatic Virtualization 1.0 Is Live," November 2025.
21. Kubermatic Virtualization Documentation, v1.1.0.
22. "What VMware Experts Need to Know about Live Migration with KubeVirt," Portworx, April 2026.
23. "Kubernetes Security and ISO 27001 Compliance," ARMO, January 2026.
24. Simplyblock, "Proxmox vs KubeVirt," March 2026.
25. "Security & Multi-Tenancy: Roles, Pools, API Tokens, and Isolation," Berik Ashimov, September 2025.
26. "Limitations of Proxmox for Enterprise Environments," Siberoloji, December 2025.
27. CNCF Case Study, "Swisscom Pioneers Sovereign Cloud with KubeVirt and Kube-OVN," May 2026.

This whitepaper reflects Kubermatic's technical perspective as of July 2026. Both Proxmox and KubeVirt are actively developed, and capabilities evolve. The architectural arguments, however, are fundamental: declarative state management, API-first design, and ecosystem extensibility are not features that can be added to an imperative system. They require an architecture built around them from the start. Kubernetes provides that architecture. KubeVirt inherits it.