readystack/virtlauncher repository overview

⁠virt-launcher

readystack/virtlauncher: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=virtlauncher⁠
• Daily scans (JSON, under readystack/virtlauncher: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=virtlauncher⁠
• 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-launcher is the main container of the pod that each KubeVirt virtual machine runs in. It starts the machine with a libvirt instance inside the pod and watches the machine's process until it exits.

Use case: When Kubernetes asks to stop a virtual machine's pod, virt-launcher passes the signal on to the machine and tries to hold off the pod's termination until the guest has shut down.

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:e29e54fb52799baff97832001ef03b29c4eba421374d43e492fd840254618d3b on 2026-10-29.

• Scan grade at release — F (0.0) on ReadyStack's own scan of the published digest sha256:e29e54fb52799baff97832001ef03b29c4eba421374d43e492fd840254618d3b, 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 23 (-230); medium_fixable 78 (-234); critical_unfixable 1 (-8); high_unfixable 35 (-105). 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-launcher, QEMU and libvirt included, 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 23 high and 78 medium findings it marks fixable. Of the 23 fixable highs, 20 are scanner false positives: 8 are matches of Debian's libssl3 3.0.22 in the image against RHEL 9's openssl advisories, because the image's os-release names CentOS Stream 9 (Debian's own data shows 3.0.22-1~deb12u2 as fixed), and 12 are libevent, pcre2, pcre2-syntax and sqlite-libs builds of CentOS Stream 9 that already carry the fix, which grype compares with RHEL's newer el9_8 builds; Docker Scout does not report any of them as fixable critical or high. The other 3 are real: pcre2 and pcre2-syntax CVE-2026-103111 and libcap CVE-2026-4878 are fixed in RHEL 9 but not yet in CentOS Stream 9. The residual list in docs/provenance/TOOLCHAIN.lock names each one, so the image cannot reach Grade A on ReadyStack's scan. ReadyStack builds KubeVirt's own virt-launcher, so QEMU and libvirt stay on the CentOS Stream 9 package set KubeVirt tests and ships, and KubeVirt v1.9.1 neither supports nor publishes a 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/virtlauncher: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:e29e54fb52799baff97832001ef03b29c4eba421374d43e492fd840254618d3b; verify with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/virtlauncher: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/virtlauncher:v1.9.1-CE-centos9-r1

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

This release is signed; verify it with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/virtlauncher: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 per-VM Pod: virt-launcher starts virtqemud and QEMU (CentOS Stream 9's qemu-kvm and libvirt, the package set KubeVirt tests and ships) as the unprivileged qemu user (uid 107). virt-handler also runs its node-labeller init container from this image, as root, which virt-operator sets.

This image runs only inside a Kubernetes cluster, started by its stack's manifests (the admin guide shows how); started on its own it exits. Its one-run check, which VERIFY_OFFLINE.sh also runs: docker run --rm --network none readystack/virtlauncher:v1.9.1-CE-centos9-r1 --help prints --allow-emulation.

⁠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:6de4ce2585821a53b982a15956d479b6edc46efcf6eeb7f5ca2dd6a37aa921c9 on 2026-10-29.

— ReadyStack · readystack.dev