test(conformance): correct stale ImageVolume-gate rationale for k3s v1.36.4

The three KubeVirt VM conformance tests (vm-lifecycle, vm-default-deny,
vm-data-survival) carried comments asserting the ALPHA `ImageVolume` feature
gate is DISABLED "on this k3s v1.31 cluster" and that the apiserver therefore
prunes the container-disk `image` volume, breaking the containerDisk boot path.

The cluster was upgraded v1.31 -> v1.36.4. Revalidated the gate live:
  - kubernetes_feature_enabled{name="ImageVolume"} = 1 (enabled by default;
    stage="" — no longer ALPHA)
  - a server-side `kubectl apply --dry-run=server` of a Pod with an `image`
    volume RETAINS the volume + mount instead of pruning them.

So the old premise is stale: containerDisk roots would boot on 1.36.4. The
tests never asserted the gate state and never used containerDisk — they boot
from CDI DataVolume roots, which remains the correct choice because it is the
spec-required, rebuild-surviving disk model (docs/06, R-STATE-01); an ephemeral
containerDisk could never satisfy data-survival. Test logic is therefore
unchanged; only the explanatory comments are corrected (v1.31 -> v1.36.4, and
the "containerDisk is broken here" rationale marked stale with the live
evidence).

Merge gate: PASS (lint, l0, render-golden, l1 green).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

conformance/tests/l2-behavioral/vm-default-deny/chainsaw-test.yaml

@@ -13,11 +13,16 @@
 #       podSelector:{} NetworkPolicy covers it). R-NET-01 for IaaS.
 #
 # METHOD (virtctl-free): the VM's ROOT is a CDI DataVolume on Longhorn (a mounted
-# PVC — NOT an ephemeral containerDisk, whose boot path is broken on this k3s cluster:
-# KubeVirt v1.9 serves the container-disk binary via a k8s `image` volume gated by the
-# ALPHA `ImageVolume` feature gate, disabled on k3s v1.31, so the apiserver prunes it
-# and the guest dies at OCI init. DataVolume roots bypass that path and are the
-# spec-required disk model — docs/06). cloud-init runs the two probes and writes a
+# PVC — NOT an ephemeral containerDisk), the spec-required, rebuild-surviving disk model
+# for VMs (docs/06, R-STATE-01), matching fixtures/vm.yaml. (Feature-gate note,
+# revalidated 2026-08: an earlier revision said the containerDisk boot path was broken on
+# this cluster — KubeVirt v1.9 serves the container-disk binary via a k8s `image` volume
+# gated by the ALPHA `ImageVolume` feature gate, which k3s v1.31 had DISABLED, so the
+# apiserver pruned it and the guest died at OCI init. That premise is now STALE: the
+# cluster is k3s v1.36.4, where ImageVolume is ENABLED by default
+# (kubernetes_feature_enabled{name="ImageVolume"}=1; a server-side dry-run RETAINS an
+# `image` volume rather than pruning it), so containerDisk roots would boot — DataVolume
+# is kept because it is the rebuild-surviving model.) cloud-init runs the two probes and writes a
 # PASS/FAIL verdict to a raw Longhorn block disk, then powers off (RerunOnFailure =>
 # stays down). A busybox reader pod reads the verdict back. The container default-deny
 # test proves the datapath fail-closed (default-deny-failclosed, L3); this asserts

conformance/tests/l2-behavioral/vm-lifecycle/chainsaw-test.yaml

@@ -21,19 +21,25 @@
 # (hermetic).
 #
 # DISK MODEL — CDI DataVolume on Longhorn (NOT an ephemeral containerDisk):
-#   KubeVirt v1.9 supplies the container-disk binary to the `volumerootdisk` init
-#   container via a Kubernetes-native `image` volume (VolumeSource.Image) mounted at
-#   /container-disk-binary. That k8s feature is gated by the ALPHA `ImageVolume`
-#   feature gate, which is DISABLED on this k3s v1.31 cluster — so the apiserver
-#   silently PRUNES the image volume + its mount, the binary is never present, and a
-#   containerDisk VM dies at OCI init with:
-#     exec: "/container-disk-binary/usr/bin/container-disk": no such file or directory
-#   A DataVolume-backed root is a mounted Longhorn PVC (CDI imports the same Fedora
-#   image into it out-of-band via its importer pod) and therefore does NOT touch the
-#   container-disk binary / image-volume path at all — it boots on this cluster. It is
-#   also the disk model the SPEC requires for VMs (docs/06, R-STATE-01: Longhorn-backed
-#   disks that survive rebuild), so this mirrors the representative fixtures/vm.yaml.
-#   Cost: a one-time CDI import per run (covered by the raised exec timeout below).
+#   The SPEC requires VMs to use Longhorn-backed disks that survive rebuild (docs/06,
+#   R-STATE-01), so this test — like fixtures/vm.yaml and the L3 vm-data-survival partner
+#   — boots from a CDI DataVolume on a Longhorn PVC (CDI imports the Fedora image into it
+#   out-of-band via its importer pod, so the VM never touches the container-disk binary /
+#   image-volume path). Cost: a one-time CDI import per run (covered by the raised exec
+#   timeout below).
+#   FEATURE-GATE NOTE (revalidated 2026-08 — the original "containerDisk is broken here"
+#   rationale is now STALE): KubeVirt v1.9 supplies the container-disk binary to the
+#   `volumerootdisk` init container via a Kubernetes-native `image` volume
+#   (VolumeSource.Image) mounted at /container-disk-binary, gated by the `ImageVolume`
+#   feature gate. On the ORIGINAL k3s v1.31 cluster that ALPHA gate was DISABLED, so the
+#   apiserver silently PRUNED the image volume + its mount and a containerDisk VM died at
+#   OCI init ("/container-disk-binary/usr/bin/container-disk: no such file or directory").
+#   The cluster is now k3s v1.36.4, where ImageVolume is ENABLED by default
+#   (kubernetes_feature_enabled{name="ImageVolume"}=1; a server-side dry-run of a Pod with
+#   an `image` volume RETAINS the volume + mount instead of pruning them). containerDisk
+#   roots would therefore boot on this cluster now — but DataVolume is retained regardless,
+#   because only it (not an ephemeral containerDisk) is the rebuild-surviving, spec-required
+#   disk model.
 # =============================================================================
 apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test

conformance/tests/l3-fault-injection/vm-data-survival/chainsaw-test.yaml

@@ -11,12 +11,19 @@
 #       (R-STATE-01 covers PaaS + IaaS).
 #
 # METHOD (virtctl-free, filesystem-agnostic, deterministic): a VM whose ROOT is a
-# CDI DataVolume on Longhorn (a mounted PVC — NOT an ephemeral containerDisk; the
-# containerDisk boot path is broken on this k3s cluster because KubeVirt v1.9 serves
-# the container-disk binary through a k8s `image` volume gated by the ALPHA
-# `ImageVolume` feature gate, which k3s v1.31 has disabled → the apiserver prunes the
-# volume and the guest dies at OCI init. DataVolume disks bypass that path and are the
-# spec-required disk model anyway — docs/06/R-STATE-01). The VM also has a SECOND
+# CDI DataVolume on Longhorn (a mounted PVC — NOT an ephemeral containerDisk). A
+# containerDisk root is EPHEMERAL — discarded when the VM is destroyed — so it could
+# never prove data-survival; the spec-required disk model here is a Longhorn-backed
+# DataVolume that OUTLIVES the VM (docs/06/R-STATE-01), which is exactly what this test
+# destroys-and-rebuilds. (Feature-gate note, revalidated 2026-08: an earlier revision
+# of this comment also claimed the containerDisk BOOT path was broken on this cluster —
+# KubeVirt v1.9 serves the container-disk binary through a k8s `image` volume gated by
+# the ALPHA `ImageVolume` feature gate, which k3s v1.31 had DISABLED, so the apiserver
+# pruned the volume and the guest died at OCI init. That premise is now STALE: the
+# cluster is k3s v1.36.4, where ImageVolume is ENABLED by default
+# (kubernetes_feature_enabled{name="ImageVolume"}=1; a server-side dry-run RETAINS an
+# `image` volume rather than pruning it), so containerDisk roots would boot — DataVolume
+# is used purely because only it survives rebuild.) The VM also has a SECOND
 # Longhorn BLOCK data disk; cloud-init writes a unique canary to that raw block device
 # and powers the guest off; runStrategy RerunOnFailure means
 # a clean shutdown STAYS down (VMI -> Succeeded), so the write is known-complete and