From Chaotic Releases to a Kubernetes-Style Governance Model

▶ Watch (2:07)

KubeVirt is roughly eight years old and spent its early years shipping features monthly with little formal process. As contributor counts grew and companies started asking about roadmaps, stability, and scale, that approach stopped working. Three years ago the project cut a GA 1.0 release and adopted a Kubernetes-style release cadence. The team chose a principle they call “KubeVirt’s razor”: if Kubernetes already solved a process problem, adopt it rather than reinvent it.

Virtualization Enhancement Proposals: Structure for a Multi-Company Project

▶ Watch (5:31)

KubeVirt borrowed the KEP format from Kubernetes and renamed it VEP, Virtualization Enhancement Proposal. Contributors open a GitHub issue describing a use case, then file a design as a pull request. Maintainers review it, ask whether a better solution exists, and either accept or request changes. Accepted VEPs are prioritized by impact and demand. The full collection of accepted VEPs doubles as the public roadmap. A dedicated “VEP open door” meeting lets anyone bring a proposal and get early feedback before writing code.

Release Cadence: Three Cycles a Year with Code Freeze and Stabilization

▶ Watch (9:45)

KubeVirt follows Kubernetes’s three releases per year. Each cycle opens with a five-week window for new VEPs and feature intake, then moves to implementation, then hits code freeze. A stabilization phase follows where contributors fix bugs and improve CI. At least two release candidates ship before a final release. KubeVirt 1.8 released the day before this talk. The next cycle already has 72 features queued. The team acknowledges that most features land late in the cycle, giving users little time to test alpha and beta builds before freeze.

VM Pool: A Native Kubernetes Way to Manage Identical VM Fleets

▶ Watch (13:23)

Sreeja Varnam used VM Pool to show the VEP process in practice. The problem: running 100 similar VMs via wrapper scripts is error-prone and breaks on API changes. The VirtualMachineInstanceReplicaSet only manages stateless VMIs and lacks rollout controls for long-lived fleets. VM Pool fills that gap. It combines the batch API style of a Kubernetes Job, the self-healing of a ReplicaSet, and the careful ordering of a StatefulSet. Each VM in the pool follows a single template. The pool controller maintains the declared replica count automatically.

VM Pool API: Replicas, Update Strategy, and Auto-Healing

▶ Watch (19:10)

The VM Pool spec exposes four key fields. replicas sets the target count. maxUnavailable caps how many VMs can be down during an update. virtualMachineTemplate defines the shared config. updateStrategy controls rollout order through selection and ordered policies. Scaling strategy uses the same policy model to decide which VMs are removed when the pool shrinks. PVCs are preserved on scale-in so they can be reused on scale-out, cutting provisioning time. A startupFailureThreshold field marks a VM unhealthy after consecutive boot failures and triggers automatic replacement.

How the VEP Process Moved VM Pool from Alpha to Beta

▶ Watch (24:13)

Forcing early design review before implementation had a measurable effect on VM Pool. The VEP defined the problem clearly, surfaced API and controller behavior questions before any code merged, and aligned reviewers early. That alignment meant reviews and feedback arrived during design, not after weeks of implementation work. The result was a move from alpha to beta without major surprises. Sreeja’s summary: going to the community meeting, presenting the intent, and getting early feedback meant the design made sense to everyone and support came quickly.

Q&A

How does KubeVirt monitor VM health? VMs support readiness and liveness probes matching the Kubernetes pod model, including HTTP probes and a QEMU guest agent that runs inside the VM and can also freeze the filesystem during volume snapshots. ▶ 25:54

Is the VEP process too much overhead for developers who just want to ship code? Luboslav argued the design step is not overhead but forces thinking about stability and future users; Sreeja confirmed the process made the VM Pool work easier, not harder. ▶ 27:28

How does KubeVirt handle the project management load on maintainers? The team pushes ownership into SIGs as much as possible and adds ceremonies like the VEP open door meeting incrementally; 72 features are already queued for the next release. ▶ 29:58

Notable Quotes

we are graduating this year u hopefully at least that’s our plan right Luboslav Pivarc · ▶ 01:10

the design in my opinion is not the not something which is overhead but something which force you to think about the future the stability about the fe about the feedback Luboslav Pivarc · ▶ 27:35

this process made uh our life easier like you go to community meeting you uh I mean provide what you wanted to do and you get early feedback Sreeja Varnam · ▶ 28:11

and of course we have for example 72 features coming in in the next release. So it’s a lot of a lot. Luboslav Pivarc · ▶ 29:58

Key Takeaways

  • KubeVirt targets CNCF graduation in 2026 and shipped release 1.8 at this event.
  • VEPs, modeled on Kubernetes KEPs, give the project a public roadmap and predictable three-per-year releases.
  • VM Pool uses a single declarative config to manage, auto-heal, and roll out updates across identical VM fleets.

About the Speaker(s)

Luboslav Pivarc is a software engineer at Red Hat and a KubeVirt maintainer with nearly three years on the project. He has worked with containers and Kubernetes since 2018 and also teaches as a seminar tutor at the Faculty of Informatics, Masaryk University.

Sreeja Varnam is a software engineer at NVIDIA with over three years of experience, currently working on the NGN (Nvidia Grid Network) platform, which provides GPU as a Service in the cloud. KubeCon EU 2026 was her first KubeCon.