readystack/virthandler repository overview

⁠virt-handler

readystack/virthandler:v1.9.1-CE-centos9-r1

Source, recipe and records

• Upstream source at this release's pinned commit (v1.9.1): https://github.com/kubevirt/kubevirt/tree/c3d19093f9c7b843b3879b18dc088911c081c39e⁠
• Defect record: https://readystack.dev/defects.html?product=virthandler⁠
• Daily scans (JSON, under readystack/virthandler:v1.9.1-CE-centos9-r1): https://readystack.dev/api/scans⁠
• Build kit: not listed on readystack.dev while this release is unlisted; ask support ([email protected]⁠)
• Report an issue: https://github.com/ReadyStackFree/readystack/issues/new?template=bug.yml&product=virthandler⁠
• Signing key (cosign): https://readystack.dev/keys/cosign.pub⁠
• Part of the Kubernetes VM Stack: https://readystack.dev/stacks/kubernetes-vm-stack⁠

A cosign-signed build of KubeVirt v1.9.1 (github.com/kubevirt/kubevirt, commit c3d19093f9c7), Apache-2.0, built clean-room from official upstream source by ReadyStack⁠.

⁠Who uses it and why

Who: Kubernetes cluster administrators who run virtual machines in their clusters with KubeVirt.

Why: virt-handler runs on every node, as a DaemonSet. It keeps each virtual machine on its node in step with the cluster's definition, reports the machine's state, and handles its node-side networking and storage.

Use case: When a virtual machine is assigned to a node, virt-handler on that node sees the assignment and has the machine's virt-launcher pod start it; when the machine is deleted, virt-handler turns it off. Changes in the machine's state are reported back to the cluster.

About the upstream project, written from its own description: https://github.com/kubevirt/kubevirt/blob/main/docs/components.md⁠ · https://github.com/kubevirt/kubevirt⁠

⁠What you get

Signature, user and attestations below were measured on the published digest sha256:32f7a08c232f0e982819b2e4d38d56c04959bb8efc3d02a86be9767b34fb340e on 2026-10-29.

• Scan grade at release — F (0.0) on ReadyStack's own scan of the published digest sha256:32f7a08c232f0e982819b2e4d38d56c04959bb8efc3d02a86be9767b34fb340e, measured 2026-10-29 (an SBOM made with syft, vulnerabilities matched with grype, scored with cerodeo-v1; syft 1.54.1, grype 0.120.1, vulnerability database v6.1.10@2026-10-29T06:23:34Z). Rubric deductions: high_fixable 17 (-170); medium_fixable 63 (-189); high_unfixable 17 (-51). This release is not listed on readystack.dev, which lists a release only when it scores A on this scan. Why it is published unlisted: KubeVirt builds virt-handler on its own CentOS Stream 9 package set. That set carries high vulnerabilities that CentOS Stream has not fixed yet, and the scan also counts 17 high and 63 medium findings it marks fixable (the scan matches Debian's libssl3 3.0.22 in the distroless base against the lower fixed versions of CentOS Stream 9's openssl, which Docker Scout and OSV do not report as fixable critical or high), so the image cannot reach Grade A on ReadyStack's scan. The request rules out rebuilding KubeVirt on another base, and KubeVirt v1.9.1 neither supports nor publishes its CentOS Stream 10 variant. ReadyStack scans this release every day as well; its first and latest scans are at https://readystack.dev/api/scans⁠ under readystack/virthandler:v1.9.1-CE-centos9-r1.
• ReadyStack release check — passed at release on 2026-10-29: no fixable critical or high vulnerability (Docker Scout and OSV), a non-root user, SBOM and provenance attached. This is ReadyStack's own test, not a Docker grade; vulnerabilities published since then are in its daily scans at https://readystack.dev/api/scans⁠.
• Signed — cosign signature by the ReadyStack release key (fingerprint 04daa92344a52dbc) on this release's index digest sha256:32f7a08c232f0e982819b2e4d38d56c04959bb8efc3d02a86be9767b34fb340e; verify with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/virthandler:v1.9.1-CE-centos9-r1.
• Attestations — An SPDX SBOM and SLSA v1 build provenance are attached to this digest.
• Runs as a non-root user (107).
• Built from source by ReadyStack.

⁠Which tag should I pull?

This image follows the ReadyStack release-tag convention:

• The current release is v1.9.1-CE-centos9-r1 — published unlisted: readystack.dev does not list it. Release tags use the pattern <upstream-version>-CE-<base-os>-r<N>; the current one is signed, attested (SBOM + provenance), and is provided under the ReadyStack Agreement⁠.

• Earlier release tags (an older version or revision in the same pattern) are superseded. They stay pullable so existing deployments can pin them, but they are no longer re-graded, and fixes appear only in newer releases: move to the current release. For a superseded release's build kit, ask support.

• Release tags never move, so pulling the same tag again never changes the image. To be offered each new release automatically (a new revision r<N+1>, or a new upstream version), use the ReadyStack Renovate preset: https://readystack.dev/updates.html⁠

• Any tag beginning with internal- is an engineering-pipeline artifact published for build observability. It is unsupported, may change or disappear without notice, and must not be used in production.

# ✓ current release
docker pull readystack/virthandler:v1.9.1-CE-centos9-r1

# ✗ unsupported (do not pull)
docker pull readystack/virthandler:internal-...

This release is signed; verify it with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/virthandler:v1.9.1-CE-centos9-r1 (the signature is recorded in the public Sigstore transparency log). Support: [email protected]⁠, as set out in the ReadyStack Agreement⁠.

⁠Deployment

the node agent (a DaemonSet): it prepares each node for VMs, hands VirtualMachineInstances to their virt-launcher Pods and reports node and VM state. It runs privileged and as root, which its Pod sets (runAsUser: 0 through the KubeVirt CR); the image's own default user is qemu (uid 107).

virt-handler runs on a node as a pod of KubeVirt's DaemonSet, which passes it --pod-ip-address, --hostname-override and a kubeconfig (--kubeconfig); the admin guide shows the DaemonSet's user and root patch, not its arguments. Started on its own with docker run -d the container exits at once with panic: no pod ip detected. To check the image alone: docker run --rm --network none readystack/virthandler:v1.9.1-CE-centos9-r1 --help, which prints the usage and exits 0.

⁠The full ReadyStack Hermetic Build Kit

The complete --network=none build kit for this image — plus admin/DB/API handbooks, the build's validation records, and its build provenance records — is not listed on readystack.dev while this release is unlisted; ask support ([email protected]⁠) for it. A clean-room rebuild from this release's archive on an egress-blocked host reproduced its linux/amd64 digest sha256:cc95abc1a3ac1202eeb71e3f3d4cab910163d8e6b141eaddbcaaf181c709a82a on 2026-10-29.

— ReadyStack · readystack.dev