RATATOSKRATATOSK
Sign in

Releases

AI-analyzed release notes for CNCF graduated and incubating projects.

Project: KubeVirtClear ×

KubeVirt

Orchestration & ManagementJun 16, 2026

KubeVirt v1.8.4 is a patch release fixing a gRPC connection leak in virt-handler that caused memory growth, patching CVE-2026-35469 in spdystream, and adding missing metrics/alerts.

  • securityPatch CVE-2026-35469 by upgrading to v1.8.4

    The moby/spdystream dependency carried CVE-2026-35469 (GHSA-pc3f-x583-g7j2). If you're on any v1.8.x release before v1.8.4, upgrade now. Check your internal scanner results for this CVE to confirm exposure before and after the upgrade.

  • breakinggRPC connection leak fix may change virt-handler resource footprint

    The connection leak in GetLauncherClient caused unbounded memory and goroutine growth when multiple controllers raced on the same VMI. After upgrading, virt-handler memory usage should drop noticeably in clusters with high VMI churn. If you have memory-based alerts or resource limits tuned to the leaked baseline, revisit those thresholds post-upgrade.

  • enhancementNew metrics and alerts for virt components — update dashboards

    Missing metrics, recording rules, and alerts were added for virt components. Review what's new against your existing Prometheus/Alertmanager setup and add any new alerts to your runbooks. This is a good time to audit alert coverage gaps you may have been living with.

Key changes (4)
  • CVE-2026-35469: moby/spdystream bumped from v0.5.0 to v0.5.1 to address GHSA-pc3f-x583-g7j2
  • Fixed gRPC connection leak in virt-handler's GetLauncherClient — caused unbounded memory growth, socket accumulation, and goroutine leaks under controller races
  • Added missing metrics, recording rules, and alerts for virt components
  • Node-labeller now uses --expand-cpu-features and --supported-cpu-features flags
Source

KubeVirt

Orchestration & ManagementJun 3, 2026

KubeVirt v1.8.3 is a patch release with 75 fixes targeting security, authorization, live migration stability, and GPU/DRA device handling — all worth deploying promptly.

  • securityPatch CVE and symlink traversal — upgrade now

    Two security issues demand attention: a gRPC CVE (GHSA-p77j-4mvh-x3m3) and a symlink traversal in the VMExport dir handler. Both are fixed in this release. If you use VMExport or expose VM data externally, treat this upgrade as urgent. Verify no malicious symlinks exist in existing VMExport directories before and after upgrading.

  • breakingRecording rule renames — update dashboards and alerts before upgrading

    kubevirt_vm_created_total and kubevirt_vm_created_by_pod_total are deprecated outright, and multiple other recording rules are being renamed for naming convention compliance. If your Grafana dashboards, alerting rules, or SLO queries reference these metrics, they will silently stop matching after upgrade. Audit your observability stack now and migrate to the new names before rolling this out to production.

  • enhancementLive migration is more reliable — especially on IPv6 and cross-namespace setups

    Several live migration bugs are resolved here: cross-namespace migration on IPv6 clusters now works, duplicate kubevirt_vmi_info series no longer break VirtualMachineStuckOnNode and VMCannotBeEvicted alerts, and GuestAgentPing probes no longer cause spurious pod restarts during migration. If you've been avoiding live migration in IPv6 or multi-namespace environments due to instability, this release clears those blockers.

Key changes (5)
  • CVE fix: gRPC bumped to 1.79.3 to address GHSA-p77j-4mvh-x3m3
  • Security: symlink traversal vulnerability patched in VMExport directory handler
  • Multi-device VFIO passthrough VMs failing to start ('cannot limit locked memory') now fixed by scaling memlock rlimit per device
  • virt-api SubjectAccessReview truncation bug fixed — deep subresources like vnc/screenshot and sev/* were being authorized against wrong names
  • GuestAgentPing probes no longer trigger virt-launcher pod restarts during live migration, snapshots, or paused VM states
Source

KubeVirt

Orchestration & ManagementJun 3, 2026

KubeVirt v1.7.4 is a patch release fixing a CVE in gRPC, authorization bugs, live migration on IPv6, and probe-triggered pod restarts during VM lifecycle events.

  • securityPatch CVE-2026-33186 by upgrading to v1.7.4 now

    The gRPC dependency was vulnerable to CVE-2026-33186. This is a direct dependency bump to 1.79.3, so upgrading your KubeVirt installation to v1.7.4 is the only required action — no configuration changes needed. Prioritize this if your cluster runs workloads exposed to untrusted input over gRPC.

  • breakingAudit authorization if you use VNC, SEV, or evacuate subresources

    The SubjectAccessReview truncation bug meant RBAC checks were being evaluated against incorrect subresource names — which could have allowed access that should have been denied, or denied access that should have been allowed. After upgrading, verify that your RBAC policies for vnc/screenshot, sev/*, and evacuate/cancel subresources behave as intended. This is not just a security fix; it's a correctness fix for authorization logic.

  • enhancementVMs using GuestAgentPing probes during migrations or pauses should no longer bounce

    If you've been seeing unexpected virt-launcher pod restarts during live migrations or VM pause operations, this was a known probe behavior issue. The fix suppresses false-positive probe failures during pre-copy target, post-copy source, user pause, snapshot, save, and dump states. No action required — just upgrade. If you had workarounds in place (e.g., disabling GuestAgentPing during migrations), you can now remove them.

Key changes (5)
  • CVE-2026-33186 remediated by bumping google.golang.org/grpc to 1.79.3
  • GuestAgentPing probes no longer trigger virt-launcher pod restarts during live migration, pause, snapshot, save, or dump operations
  • Cross-namespace live migration now works correctly on IPv6 clusters
  • Fixed virt-api SubjectAccessReview bug that caused authorization checks against wrong subresource names for vnc/screenshot, sev/*, and evacuate/cancel endpoints
  • PCI hostdev VMs no longer fail to restart after hotplugging a block volume; PCI topology now gates on machine type, not just architecture
Source

KubeVirt

Orchestration & ManagementJun 3, 2026

KubeVirt v1.6.6 is a patch release fixing 9 notable bugs including a CVE remediation, authorization bypass in virt-api, and broken cross-namespace live migration on IPv6 clusters.

  • securityPatch CVE-2026-33186 by upgrading to v1.6.6

    The grpc dependency was bumped to remediate CVE-2026-33186. If your KubeVirt deployment exposes gRPC endpoints or you're running in a multi-tenant cluster, this is the main reason to push this upgrade now. Check your current version and plan the rollout — this is a patch release so the upgrade path should be straightforward.

  • securityFix incorrect SubjectAccessReview checks in virt-api — audit your RBAC

    virt-api was constructing SubjectAccessReviews with truncated subresource names for deep paths like vnc/screenshot and sev/*. This means authorization checks were running against wrong resource names, potentially allowing or denying access incorrectly. After upgrading, audit any RBAC policies that restrict access to VNC, SEV, or evacuation subresources to confirm they behave as intended.

  • breakingIPv6 clusters: cross-namespace live migration was silently broken — verify after upgrade

    If you're running KubeVirt on an IPv6 cluster and rely on cross-namespace live migrations, those migrations were failing. This fix restores the expected behavior. After upgrading, run a test migration across namespaces in your IPv6 environment to confirm the fix holds before relying on it in production workflows.

  • enhancementPCI hostdev users on mixed machine types: restart reliability improved

    VMs using PCI passthrough hostdevices were failing to restart after hotplugging a block volume. The root cause was PCI topology being gated only on architecture, not machine type. If you manage VMs with PCI hostdevices and have seen unexplained restart failures post-hotplug, this patch resolves it — no config change needed, just the upgrade.

Key changes (5)
  • CVE-2026-33186 patched via grpc bump — update immediately if running in environments with untrusted gRPC traffic
  • virt-api was truncating subresource paths (vnc/screenshot, sev/*, evacuate/cancel) in SubjectAccessReviews, causing auth checks to silently pass against wrong subresource names
  • Cross-namespace live migration now works correctly on IPv6 clusters — previously broken
  • PCI topology now gated on machine type instead of architecture alone, fixing VM restart failures after hotplug block volume with PCI hostdevices
  • AgentUpdated events now fire only on actual domain info changes, reducing unnecessary event noise in clusters using QEMU guest agent
Source

KubeVirt

Orchestration & ManagementApr 24, 2026

KubeVirt v1.7.3 is a focused patch release fixing 11 bugs across live migration, ARM64/s390x guest support, VMExport, and virt-handler stability.

  • breakingBackend storage volume name has changed — check existing VMs

    VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' instead of a name derived from the VM name. If you have monitoring, automation, or tooling that references the old volume name pattern, update those references before upgrading. Verify existing VMs with backend storage in your environment to understand impact before rolling out v1.7.3.

  • enhancementUpgrade if you run ARM64 or s390x guests, or use decentralized live migration

    Three targeted fixes land for non-x86 architectures: ARM64 SMBIOS visibility and s390x PCIe controller errors are both resolved. Separately, decentralized live migration now correctly reports success and supports Windows VMs requiring Hyper-V enlightenments. If any of these scenarios apply to your cluster, this patch is worth prioritizing over staying on v1.7.2.

  • enhancementvirt-handler socket recovery is now automatic — no more manual pod restarts

    Two separate fixes address domain-notify server crashes and socket deletion. Previously, a deleted or crashed notify socket would leave virt-handler in a broken state requiring manual intervention. After upgrading, this recovers automatically. If you've been seeing unexplained VM communication failures on nodes, this is likely the culprit.

Key changes (5)
  • virt-handler now detects and auto-restarts the domain-notify server when the socket is deleted or exits unexpectedly — previously this caused silent failures
  • Fixed live migration reporting and enlightenment support after decentralized live migration sequences
  • ARM64 guests can now see SMBIOS system information; s390x VMs no longer fail due to unsupported PCIe root-port controllers introduced in v3 PCI topology
  • Backend storage volume names now use the fixed label 'persistent-state-for-this-vm' instead of embedding the VM name, which was causing truncation issues
  • VMExport failures with long PVC names fixed; memory dump PVCs now labeled correctly to support CDI WebhookPvcRendering
Source

KubeVirt

Orchestration & ManagementApr 24, 2026

KubeVirt v1.6.5 is a patch release with 61 fixes targeting decentralized live migration reliability, virt-handler stability, and monitoring accuracy.

  • breakingBackend storage volume rename may affect existing tooling

    VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' rather than a name derived from the VM name. If you have scripts, dashboards, or alerts that reference the old volume naming pattern, update them before upgrading. Check if any PVC-based tooling depends on that name convention.

  • enhancementUpgrade if you rely on decentralized live migration

    Three separate bugs in decentralized live migration are fixed here: cross-volumeMode failures, broken migration for enlightened (Hyper-V) VMs, and incorrect 'succeeded' status reporting after compute migration. If your cluster runs Windows VMs or mixes volume modes, this patch directly unblocks those scenarios. Prioritize this upgrade over staying on v1.6.4.

  • enhancementMonitoring alert baselines are now more accurate

    The low-count alert for KubeVirt components now fires based on the configured replica count in the deployment, not a hardcoded value. Non-schedulable nodes are also excluded from kubevirt_allocatable_nodes. Review your existing alert thresholds after upgrading — alerts may behave differently if your environment has non-schedulable nodes or custom replica counts.

Key changes (5)
  • virt-handler now auto-recovers when domain-notify.sock is deleted, preventing silent VM communication failures
  • Decentralized live migration gets multiple fixes: cross-volumeMode migrations complete successfully, enlightened VMs can migrate again, and migration status now correctly reports 'succeeded' after compute migration
  • Backend storage volumes now use a stable name ('persistent-state-for-this-vm') instead of embedding the VM name, which affects volume naming for existing VMs
  • Monitoring improvements: kubevirt_allocatable_nodes excludes non-schedulable nodes, and low-count alerts now use the deployment's configured replica count as baseline
  • Infinite VMI status update loop between virt-controller and virt-handler fixed when primary NIC was listed after secondary NICs in the spec
Source

KubeVirt

Orchestration & ManagementApr 20, 2026

KubeVirt v1.8.2 is a patch release with 12 bug fixes covering hotplug volumes, live migration, TLS config, qcow2 disk handling, and multi-arch VM stability.

  • breakingBackend storage volume naming changed — check for impacts

    VMs using backend storage volumes will now report the volume name as 'persistent-state-for-this-vm' instead of a name derived from the VM name. If you have monitoring alerts, scripts, or tooling that match on the old volume name pattern, they will silently break. Audit any automation that references backend storage volume names before upgrading.

  • enhancementUpgrade s390x and ARM64 clusters — arch-specific VM failures resolved

    Two separate fixes land here: ARM64 guests now correctly expose SMBIOS system info, and s390x VMs failing to create due to unsupported PCIe root-port controllers from the v3 PCI topology change are fixed. If you're running multi-arch clusters and held back on v1.8.x due to these issues, v1.8.2 is the version to move to.

  • enhancementTLS config from KubeVirt CR now respected by sync-controller and virt-exportserver

    Previously, the sync-controller healthz server and virt-exportserver ignored the TLSConfiguration set in the KubeVirt CR, potentially using weaker defaults. After upgrading, verify your KubeVirt CR TLS settings are correct — they'll actually take effect now. This matters most for clusters with strict cipher or TLS version requirements.

Key changes (6)
  • virt-handler now auto-restarts the notify server when domain-notify.sock is deleted, preventing silent VM communication failures
  • Hotplug volumes stuck in 'Detaching' phase are now correctly resolved
  • Fixed migration status not reporting 'succeeded' after decentralized live migration with compute migration
  • qcow2 overlay disks now correctly resolve source, preventing wrong disk expansion and incorrect cache/IO mode
  • s390x VM creation failures from unsupported PCIe root-port controllers (introduced in v3 PCI topology) are fixed
  • Backend storage volumes now use a stable name 'persistent-state-for-this-vm' instead of embedding the VM name
Source

KubeVirt

Orchestration & ManagementMar 30, 2026

KubeVirt v1.8.1 is a small patch release fixing two specific bugs: virt-handler domain-notify server crashes and VMExport failures with long PVC names.

  • breakingUpgrade if virt-handler crashes are disrupting VM lifecycle events

    The domain-notify server handles communication between virt-handler and running VMs. If it exits unexpectedly without restarting, VMs can become unresponsive to lifecycle operations (start, stop, migrate) without obvious errors. If you've seen unexplained VM management failures after a virt-handler pod restart, this is your fix. Patch as soon as possible on v1.8.0 clusters.

  • enhancementVMExport now works reliably with long PVC names — review your naming conventions

    If you use VMExport for backup or migration workflows and your PVCs follow long naming patterns (common with dynamic provisioners or namespace-prefixed names), test VMExport after upgrading. The prior failure was silent enough to cause confusion — confirm your export pipelines are functional post-upgrade.

Key changes (3)
  • virt-handler's domain-notify server now restarts automatically on unexpected exit, preventing silent VM communication failures
  • VMExport no longer fails when PVC names exceed certain length limits
  • 17 files changed across 17 PRs from 7 contributors — tight, focused patch
Source

KubeVirt

Orchestration & ManagementMar 24, 2026

KubeVirt v1.8.0 is a large release (1242 changes, 77 contributors) adding a new VM backup API, VMPool auto-healing, containerpath volumes, and multiple network/storage improvements with several breaking removals.

  • breakingRemove SLIRP and Macvtap network bindings before upgrading

    Both core SLIRP and Macvtap bindings are completely removed in v1.8.0. If any VMs in your cluster use these bindings, they will break post-upgrade. Audit your VM specs now with a label/annotation query, migrate affected VMs to passt or bridge bindings, and validate in a non-prod environment before rolling this to production.

  • breakingUpdate migration metrics in dashboards before upgrading

    kubevirt_vmi_migration_data_total_bytes is deprecated and will eventually be removed. If you have Grafana dashboards, Prometheus alerts, or recording rules referencing this metric, update them to kubevirt_vmi_migration_data_bytes_total now. Also note the vCPU recording rule rename from kubevirt_vmi_vcpu_count to vmi:kubevirt_vmi_vcpu:count — both need updating together.

  • enhancementAdopt explicit feature gate disabling for tighter cluster governance

    You can now explicitly block feature gates via disabledFeatureGates in the KubeVirt config rather than relying on gates simply being absent. For clusters where you want to enforce that certain alpha/beta features stay off (e.g., in regulated environments), add them to the disabled list. This is particularly useful if you're managing KubeVirt configs via GitOps and want auditable gate enforcement.

Key changes (6)
  • Core SLIRP and Macvtap network bindings permanently removed — any VMs using these must migrate to alternatives before upgrading
  • New VMBackup API introduced for incremental backups, including CBT (Changed Block Tracking) support after VM restart
  • VMPool v1beta1 graduates with auto-healing strategy and scale-in control (proactive/opportunistic modes with state preservation)
  • Feature gates can now be explicitly disabled via kv.spec.configuration.developerConfiguration.disabledFeatureGates
  • Metric rename: kubevirt_vmi_migration_data_total_bytes deprecated in favor of kubevirt_vmi_migration_data_bytes_total — update dashboards and alerts
  • VIRT_*_IMAGE env var overrides on virt-operator now correctly propagate to component deployments (was silently broken before)
Source

KubeVirt

Orchestration & ManagementMar 16, 2026

KubeVirt v1.7.2 is a patch release fixing 7 bugs across networking, storage, monitoring, and backup — no new features, but several fixes that could unblock production issues.

  • breakingCheck VMI specs if you're running mixed NIC configurations

    The infinite status loop fix targets VMIs where the primary network interface appears after a secondary one in the spec. If you have VMs stuck in update churn or virt-controller/virt-handler showing abnormal CPU/log volume, this is likely the cause. Upgrade to v1.7.2 and verify your VMI specs list the primary interface first to avoid re-triggering the issue on older clusters.

  • enhancementWindows VM backup users should update for reliable Velero integration

    The QuiesceFailed-to-QuiesceTimeout change plus a 60s pre-backup hook timeout directly addresses flaky Windows VSS snapshot behavior during Velero backups. If you're backing up Windows VMs and seeing intermittent quiesce failures, this patch resolves it. Review your Velero backup policies to ensure the hook timeout aligns with your SLAs.

  • enhancementGoogle Cloud NetApp Volumes storage migration is unblocked

    If you're running VMs on GCP with NetApp Volumes and tried live storage migration, it was silently failing. This patch fixes that. Test your migration workflows after upgrading — especially if you deferred any storage moves because of this bug.

Key changes (7)
  • Fixed infinite VMI status update loop when primary NIC is listed after secondary interfaces in the VMI spec
  • Fixed PCI address stability across upgrades when using v3 hotplug port topology
  • Fixed storage migration failures with Google Cloud NetApp Volumes
  • Corrected kubevirt_allocatable_nodes metric to exclude non-schedulable nodes
  • Replaced QuiesceFailed with QuiesceTimeout for Windows VSS backups, adding a 60s Velero pre-backup hook timeout
  • Fixed low-replica alerts to use the deployment's defined replica count as the baseline
  • Fixed socket devices failing to update health status when Persistent Reservations is enabled
Source

KubeVirt

Orchestration & ManagementMar 16, 2026

KubeVirt v1.6.4 is a patch release with 108 changes targeting stability: a CVE fix in crypto, several hotplug/migration bugs squashed, and new vCPU queue alerting.

  • securityPatch CVE-2025-47913 — upgrade to v1.6.4 now

    CVE-2025-47913 affects the golang/x/crypto dependency. This release pins it to OpenShift's patched fork. If you're running any v1.6.x release before v1.6.4, you're exposed. Upgrade immediately — no workaround exists short of patching the binary yourself.

  • breakingCross-vendor live migrations are now blocked

    KubeVirt will now explicitly prevent live migrations between nodes with different CPU vendors (e.g., Intel to AMD). If your cluster has mixed CPU vendors and you've been relying on cross-vendor migration — intentionally or not — audit your node topology before upgrading. Migrations that previously succeeded may now fail with an error.

  • enhancementAdd vCPU queue alerts to your monitoring setup

    Two new alerts ship in this release: GuestPeakVCPUQueueHighWarning and GuestPeakVCPUQueueHighCritical. If you're running KubeVirt with Prometheus, check that these alerts are picked up by your alerting rules. They give you early warning on guest CPU starvation, which is otherwise invisible until VMs start misbehaving under load.

Key changes (5)
  • CVE-2025-47913 remediated by redirecting golang/x/crypto to the patched openshift/golang-crypto module
  • PCI address stability fixed across upgrades when using v3 hotplug port topology
  • Block volume hotplug no longer breaks autoattachVSOCK
  • New Prometheus alerts: GuestPeakVCPUQueueHighWarning and GuestPeakVCPUQueueHighCritical for guest CPU saturation visibility
  • Memory overcommit is now recalculated on live migration, and cross-vendor migrations are explicitly blocked
Source

KubeVirt

Orchestration & ManagementFeb 23, 2026

KubeVirt v1.7.1 delivers critical bug fixes for live migration, volume hotplug, and VM snapshot operations, along with enhanced monitoring capabilities and security updates.

  • securityUpdate to address crypto dependency vulnerabilities

    The golang.org/x/crypto dependency was updated to v0.45.0 to address security issues. Plan to upgrade to this version promptly, especially in production environments handling sensitive workloads, as crypto vulnerabilities can impact VM security.

  • breakingCross-vendor migration prevention requires review

    KubeVirt now prevents cross-vendor migrations which may break existing workflows that rely on migrating VMs between different infrastructure providers. Review your migration patterns and ensure source and target nodes use compatible virtualization stacks.

  • enhancementImplement ephemeral volume monitoring

    New metrics and alerts for ephemeral hotplug volumes improve operational visibility. Configure your monitoring stack to capture these new metrics and set up alerts for ephemeral volume lifecycle events to better track resource usage and potential issues.

Key changes (6)
  • Fixed decentralized live migration issues between volumes with different volumeModes
  • Resolved block volume hotplug breaking autoattachVSOCK functionality
  • Added ephemeral hotplug volume metrics and alerts for better monitoring
  • Fixed missing migration metrics that impacted observability
  • Updated security dependencies including golang.org/x/crypto to v0.45.0
  • Enhanced VM export functionality to work with PVCs from completed pods
Source