| 12:00 PM | "Welcome to KubeVirt Summit", by Andrew Burden (KubeVirt) | Welcome to KubeVirt Summit 2026, celebrating 10 years of KubeVirt! |
| 12:10 PM | "Can Your CI Control Plane Move Without Stopping? Jenkins Live Migration with KubeVirt", by Aisvarya S (Silicon Labs) | Jenkins controllers are often among the most operationally sensitive workloads in an engineering platform. They maintain pipeline state, coordinate agents, schedule builds, manage plugins, and serve as the control plane for software delivery. Yet controller maintenance frequently involves a difficult choice: interrupt active pipelines or postpone critical infrastructure work.
What happens when the Jenkins controller becomes a live-migratable Kubernetes workload?
This session explores an architecture in which the Jenkins controller runs inside a KubeVirt virtual machine while ephemeral build agents continue to run as Kubernetes pods. This hybrid model combines the isolation and operating-system compatibility of a virtual machine with Kubernetes-native scheduling, automation, and elastic agent provisioning.
We will follow the complete lifecycle of the design: exposing the controller reliably to dynamically created agents, choosing WebSocket-based inbound agent connectivity, separating persistent controller state from the VM lifecycle, and preparing the workload for KubeVirt live migration. We will examine how shared storage, pod-network masquerade, eviction strategies, disruption controls, migration bandwidth, and node maintenance procedures influence the availability of the Jenkins control plane.
The session will also discuss what "minimal downtime" actually means for Jenkins. Live migration can keep the guest operating system and controller process running, but successful continuity also depends on stable service addressing, persistent network connections, storage latency, JVM behavior, and the ability of agents to reconnect without losing pipeline execution.
Rather than presenting virtualization as an alternative to containers, this talk demonstrates how virtual machines and pods can serve different roles within the same cloud-native CI architecture: a durable, migratable controller running in KubeVirt and disposable, scalable agents running directly on Kubernetes.
Attendees will leave with a practical architectural blueprint, the migration prerequisites that matter most, the failure modes that should be tested, and a framework for deciding whether a Jenkins controller is a strong candidate for KubeVirt.
Key Takeaways:
1. How to design a hybrid Jenkins architecture with a KubeVirt-based controller and Kubernetes pod agents.
2. The storage, networking, scheduling, and disruption-management prerequisites for live migration.
3. Which Jenkins components and connections remain vulnerable during migration despite the guest continuing to run. |
| 12:30 PM | "Structured Plugins: Making KubeVirt Extensible", by Itamar Holder (KubeVirt) | KubeVirt's sidecar-hook mechanism served us well, but it hit its limits - raw libvirt XML manipulation, no node-level operations, no admission integration, and no way to build complex out-of-tree features without forking.
VEP 190 introduces Structured Plugins - a comprehensive plugin system that changes how KubeVirt can be extended. In this talk, I'll cover:
- Why we needed this: the pain points of the old hook model and what drove us to rethink extensibility.
- The four pillars: domain hooks (CEL & gRPC), node hooks (DaemonSet-based lifecycle handlers), admission policies, and the Plugin CRD that ties it all together.
- The Plugin SDK: a Go toolkit that lets you define a plugin easily and quickly and generate all deployment artifacts - CRs, DaemonSets, RBAC, Dockerfiles - with a single command.
Whether you're a KubeVirt developer looking to move features out-of-tree, or an operator wanting to customize VM behavior without maintaining a fork, this talk will show you how structured plugins open up KubeVirt's architecture. |
| 1:00 PM | "Virtualization-as-a-Service: Running Windows VM Fleets on KubeVirt + Managed Kubernetes", by Ramkumar Nagaraj (Adobe) | Kubernetes was built for containers - but plenty of enterprise workloads still live in VMs, especially Windows. This talk walks through how we built a self-service Virtualization-as-a-Service platform on KubeVirt running over managed Kubernetes (EKS), so internal teams can deploy and scale Windows VM fleets the same GitOps way they ship containers.
We'll cover the practical building blocks and the lessons learned: scheduling VMs onto autoscaled bare-metal nodes alongside container workloads; managing golden images with CDI and fast snapshot-based cloning (minutes to seconds); giving VMs cloud-IAM identity without static credentials; and wiring VirtualMachinePool deployments, autoscaling, and rolling updates through a standard GitOps pipeline. We'll also share the operational reality - the runbooks, dashboards, upgrade and node-drain procedures, and the sharp edges we hit so you don't have to.
Whether you're evaluating KubeVirt for a VM platform or already running one, you'll leave with a concrete reference architecture and a candid list of what worked, what didn't, and what we'd do differently. Production patterns like these are still scarce in the KubeVirt community, so the session also feeds real-world lessons - and upstream contributions - back to the project.
Benefits to the KubeVirt / CNCF ecosystem:
Most KubeVirt material is demos and proofs-of-concept; production patterns at real scale are still scarce. This talk shares a battle-tested reference architecture and the honest operational details, benefiting the ecosystem by:
- Filling the production gap: a working blueprint for VM platforms on KubeVirt over managed Kubernetes that others can adapt instead of starting from scratch.
- Advancing Windows-on-KubeVirt (still underserved): golden-image management, fast snapshot cloning, VirtIO drivers, and cloud-identity for VMs as reusable patterns.
- Lessons from failure: surfacing the sharp edges/gaps we hit (and workarounds) helps adopters avoid them and shows maintainers where the project can improve.
- Giving back upstream: fed issues/docs/fixes to kubevirt/kubevirt and kubernetes (e.g., VMI /scale + PodDisruptionBudget behavior, owner-chain traversal); reinforces that loop.
- Lowering the adoption barrier: shows KubeVirt + CDI + autoscaled bare-metal working end-to-end so more teams confidently choose KubeVirt for VM workloads. |
| 1:30 PM | "Multi-OS E2E Application testing with LLM Agents on Kubervirt", by Vedant Padwal (Stealth Startup) | Traditional CI/CD pipelines are very good at tests that run inside a container. this model doesn't scale for GUI rich applications, especially when you want to test your app across all the platforms, As coding agents have increased the velocity of multi-platform applications getting shipped into production, application reliability and quality can become the bottleneck. scripted tests although useful leave lot of edge cases and test basic features rather than complex workflows. e2e LLM based GUI agents can fill in the Gaps across different OS systems since many of them are vision based.
KubeVirt can provide the missing execution layer for this. Instead of building a separate test platform for every operating system, we can manage complete virtual machines alongside containers using the same Kubernetes cluster. Each test can start from a clean image with its own storage, network access, application state, and evidence, and the VM can be removed after the run.
This also makes it possible to fan out tests across different operating systems, application versions, configurations, and test ideas. Agents can explore workflows or fuzz parts of the application in parallel without sharing state with each other. A failure in one VM does not affect the other tests or the original image. The screenshots, action history, logs, and final state from every run can be preserved and checked before the result is accepted.
In this talk, we show a working implementation across Android, Linux, and Windows. The demo follows a GUI test from VM creation to execution, verification, and cleanup. We also share results from fifteen clean-state runs on Azure KubeVirt, five on each operating system, and discuss how the same model can be extended into a larger multi-platform testing fleet. |
| 1:45 PM | "Teaching an AI to Debug KubeVirt CI: Building Claude Code Skills for Automated Failure Analysis", by Daniel Hiller (KubeVirt) | KubeVirt's CI runs hundreds of e2e test jobs across multiple Kubernetes versions, SIGs, and architectures. When builds fail, triaging them means navigating Prow logs, testgrid data, flakefinder reports, k8s-reporter artifacts, etcd profiles, and container logs - a process that can take 30+ minutes per failure and requires tribal knowledge about infrastructure flake patterns vs. genuine regressions.
We built a suite of Claude Code "skills" - composable, AI-driven workflows - on top of a Go CLI tool in kubevirt.io/ci-health that automate this entire triage process. The skills form a layered debugging toolkit:
- Single-build analysis extracts error snippets, downloads k8s cluster state (pods, nodes, events, VMIs), profiles etcd storage, and cross-references container logs to distinguish infrastructure flakes from test bugs
- PR-wide analysis correlates failures across all jobs in a pull request, detecting whether failures are PR-caused (same test failing everywhere) or coincidental flakes (different tests in different jobs)
- Historical flake detection looks up each failing test against flakefinder data, classifying failures by success rate, failure dispersion across lanes, and periodic-vs-presubmit divergence
- Lane health analysis fetches raw testgrid data and applies flip-rate analysis, burst detection, and cross-test correlation to separate genuine flakes from deterministic regressions and infrastructure events
- Change relevance mapping checks whether a PR's changed files overlap with the failing test's code area, answering "could my PR have caused this?"
- Unified flake overview combines all data sources into a cross-project report with trend detection, quarantine prioritization, and GitHub issue tracking
Each skill suggests follow-up skills based on its findings, creating natural investigation chains. The Go CLI handles data fetching and structured extraction; the AI handles pattern recognition, cross-referencing, and natural-language summarization.
This talk will demo the skills live on real KubeVirt CI failures, show how the Go tool and Claude Code skill definitions work together, and discuss what we learned about encoding CI debugging expertise into AI-consumable instructions.
|
| 2:00 PM | "Beyond Benchmarking: AI-Powered Validation and Recovery Testing for KubeVirt", by Dhruv Bhatnagar (Everpure) & Bhumitra Nagar (Everpure) | At KubeCon Europe, we introduced virtbench, an open-source framework for benchmarking KubeVirt environments. Since then, virtbench has evolved into an AI-assisted validation platform that continuously tests performance, resiliency, and recovery across production-scale KubeVirt deployments.
Modern virtualization platforms must validate far more than VM performance. They need to exercise boot storms, live migrations, storage failovers, node failures, capacity limits, and recovery workflows across hundreds or thousands of virtual machines while identifying regressions before they reach production.
In this session, we'll demonstrate how virtbench orchestrates complex KubeVirt validation scenarios, automates failure injection and recovery testing, analyzes benchmark results using AI, detects anomalies, pinpoints infrastructure bottlenecks, and generates actionable insights. Attendees will see how AI transforms repetitive validation into continuous confidence for operating KubeVirt at scale. |
| 2:30 PM | "WG-AIE: Upstreaming GPU Passthrough for NVIDIA AI-Factory Platforms", by Lee Yarwood (Red Hat) & Fan Zhang (Nvidia) | Earlier this year Red Hat and NVIDIA independently built GPU passthrough support for NVIDIA AI-Factory platforms on separate KubeVirt branches: release-1.8-aie-nv from Red Hat and release-1.7-aie-nv from NVIDIA. Through WG-AIE (Working Group - Accelerated Infrastructure Enablement) we brought these two implementations together, taking the best of each to produce a VEP that merged into v1.9 with IOMMUFD-based device assignment and SMMUv3 support for Grace Hopper and Grace Blackwell.
In this talk the WG co-chairs will cover how that convergence worked, what we learned from merging competing approaches, and what comes next: Vera Rubin enablement, advanced features like vEGM and vCMDQ, ARM Secure Boot, Confidential Computing (CCA), CXL Type-2 passthrough, and the CentOS Stream 10 transition that will retire the current virt-launcher fork. We will also discuss how WG-AIE operates as a model for cross-vendor collaboration in KubeVirt, and how the new Structured Plugins framework shapes our upstream roadmap for launcher image selection and hardware-specific extensions. |
| 3:00 PM | "Secondary networks for KubeVirt VMs with DRA", by Sören Henning (Kubermatic) | Multus is the established way to give a KubeVirt VM a secondary network. KubeVirt's VEP-183 opens a second path. VMs can now consume NICs allocated through Kubernetes Dynamic Resource Allocation (DRA) instead.
Instead of attaching a secondary network implicitly, through CNI ADD/DEL calls the container runtime makes during pod sandbox setup, we'll show how a DRA ResourceClaim is a first-class API object with its own allocate/reserve/release states the scheduler reasons about before a pod ever lands on a node.
DRA's structured parameters handle IPAM and subnet selection cleanly during resource preparation. But DRA alone only decides what a pod should get, not how it gets wired in. The actual cni related things like veth pair creation still need to happen somewhere, and for network devices that means an NRI (Node Resource Interface) plugin acting inside the container runtime's RunPodSandbox window. A proof-of-concept DRA+NRI driver for OVN-Kubernetes showed this split works in principle. DRA handles allocation, NRI handles runtime attachment, driving a real CNI's dataplane instead of just exposing hardware.
This talk takes that split and shows how a KubeVirt network binding plugin for Kube-OVN completes the picture. Tested against real VMs, not just pods.
We'll start with the theory, how each model works, where DRA fits, and where Multus still wins, then move into a live demo that proves the DRA path works, including connecting to a VM's secondary NIC via ssh to its raw address, making it easy to try it out on your own. |
| 3:30 PM | "Migrating VM-Based Infrastructure to Cloud-Native: A Telecom-Scale Case Study", by Suresh Tambe (T-mobile) | Telecommunications systems generate billions of records daily from network events, billing systems, and customer interactions, yet most legacy architectures, including VM-heavy infrastructure, were never designed for this scale. As data volumes grow, migrating off traditional VM-based systems toward cloud-native, Kubernetes-oriented infrastructure becomes an operational necessity rather than a future priority.
This talk presents a real-world migration of a telecom-scale data platform from a VM-heavy, on-premises footprint to a cloud-native distributed architecture. Drawing from a production implementation that processes approximately 3 billion records across multiple target tables, the session covers how reducing on-premises VM infrastructure and shifting workloads onto modern orchestration platforms enabled a reduction in total processing time from 60 hours to 3.5 hours, an order of magnitude improvement achieved through architectural redesign rather than added infrastructure spend.
A central challenge addressed during the migration was customer identity fragmentation. Telecom users interact across multiple devices, accounts, and service channels, creating identity relationships too complex for the relational systems that VM-based infrastructure typically supported. This session examines how hybrid deterministic and probabilistic identity resolution, combined with graph-based models, scaled to billions of nodes as the platform moved off legacy VMs, enabling fraud detection, churn prediction, and customer segmentation at enterprise scale.
A configuration-driven pipeline framework is also presented, eliminating redundant pipeline implementations by externalizing source-to-target mappings and transformation logic. This approach, adopted as part of the broader move away from VM-based infrastructure, yielded approximately 90% reduction in operational and cloud resource costs.
Attendees will walk away with concrete lessons on planning a VM-to-cloud-native migration at scale, including distributed ingestion, lakehouse storage design, identity system modeling, and cost-efficient pipeline governance, applicable to any organization managing the transition off traditional VM infrastructure. |
| 3:55 PM | Closing Remarks | Thanks for attending the 6th annual KubeVirt Summit!
Get home safely! |
