KubeVirt makes it technically possible to run VMs on Kubernetes. Whether that turns into one genuinely unified platform, or a Kubernetes cluster with VMs bolted awkwardly on the side, comes down to four things applying consistently across both workload types.
One namespace model
Containers and VMs belonging to the same application should live in the same namespace, subject to the same quotas and network policies — not split across a Kubernetes namespace for one and a separate hypervisor folder for the other.
One access-control system
If RBAC governs container actions but VM actions go through a different login and a different permission model, "who can do what" no longer has a single answer. Real unification means the same RBAC policy — see RBAC best practices — checks both, consistently.
One observability stack
Topology graphs, event timelines and metrics-backed alerting are only genuinely useful if they show containers and VMs together — a dashboard that only shows half the workloads sharing a namespace isn't observability, it's a partial view with a false sense of completeness.
One audit trail
When an incident review has to correlate a container-platform audit log with a separate hypervisor log by timestamp, the "one platform" promise has already broken down operationally, whatever the marketing said.
What teams actually get from this
Done properly, application owners get self-serve create flows with clear namespace context — for VMs and containers alike — instead of filing a ticket and waiting on whichever team owns the other platform. Security teams get one place to align admission control, scanning and runtime signals instead of two.
How AetherVirt delivers this in practice
AetherVirt was built around this exact requirement: KubeVirt VMs as first-class Kubernetes objects, sharing namespaces, RBAC, observability and the audit trail with every container next to them — not a second console with a shared login page.