Bumping platform KubeVirt to ≥1.9 will break containerDisk VMs on non-Talos (k3s) bundles (default-on ImageVolume) #3190

Context

KubeVirt v1.9 enables Beta feature gates by default (kubevirt@6a8dfaf), turning on ImageVolume. From v1.9 the containerDisk path delivers its container-disk binary through a native Kubernetes image volume (KEP-4639) instead of the classic cp init container. Native image volumes require CRI (containerd) support.

Actual root cause (updated per k3s-io/k3s#14323)

This is a containerd version matter, not a k3s build defect. On k3s < 1.36.2 the bundled containerd 2.2.3 does not support image volumes, so the volume mounts empty and every containerDisk-backed VM fails to start with:

exec: "/container-disk-binary/usr/bin/container-disk": no such file or directory

k3s v1.36.2 bundles containerd v2.3.2, which supports image volumes — so on k3s ≥ 1.36.2 the KubeVirt v1.9 containerDisk path works and there is nothing to mitigate. Confirmed by the k3s maintainer in k3s-io/k3s#14323, who also notes the silent-empty-mount (rather than a loud error) is an upstream Kubernetes design decision, not a k3s bug.

Verified breaking on k3s v1.36.1+k3s1 / containerd v2.2.3-k3s1. Related: kubevirt#17460.

When it bites

Stock v1.5.x ships KubeVirt v1.8.2 (Beta gates off) → not affected today. It appears only when the platform KubeVirt is bumped to ≥1.9 AND the node runs k3s < 1.36.2 (containerd < 2.3.2). On k3s ≥ 1.36.2, or on Talos, it is a non-issue.

Suggested handling

When bumping platform KubeVirt to ≥1.9 on non-Talos bundles, require k3s ≥ 1.36.2 (containerd ≥ 2.3.2). For clusters still on older k3s, an interim workaround is spec.configuration.developerConfiguration.disabledFeatureGates: [ImageVolume] in the KubeVirt CR (backward-compatible; a no-op where the gate was already off) until the k3s upgrade lands.

Note: main already sidesteps this for the kubernetes app by moving workers to Talos + persistent DataVolume root (#2931).