Merge fix/kubevirt-vm-boot: real-KVM DataVolume VMs (R-PLAT-03/04 green; useEmulation:false, EFI, DataVolume roots)

platform/kubevirt/kubevirt-cr.yaml

@@ -3,20 +3,25 @@
 # operator (platform/kubevirt/kustomization.yaml), so this is applied by the `platform-config` Flux
 # Kustomization (dependsOn: platform) — see platform-config/kustomization.yaml + F-MON1.
 #
-# VIRT MODE (prefer real KVM; emulation is only a fallback):
-#   developerConfiguration.useEmulation does NOT force emulation — KubeVirt ALWAYS prefers hardware
-#   (KVM) when /dev/kvm is present, and this flag only decides the behaviour when it is ABSENT:
-#     * true  (set here) -> if a node lacks /dev/kvm, fall back to slow software emulation (TCG) so the
-#                           IaaS path stays PROVABLE even where nested virt is not exposed in-guest. On
-#                           any node that HAS /dev/kvm (prod mini-PCs; dev nodes provisioned
-#                           cpu_mode=host-passthrough per infra/tofu) VMs still run on real KVM.
-#     * false            -> a node without /dev/kvm cannot schedule VMs at all (fail loud).
-#   `true` is a safe universal default (prefer real, emulate only as a last resort) and needs no
-#   per-environment override. RUNBOOK STEP 1 is to confirm `/dev/kvm` on a node (`virt-host-validate` /
-#   `ls -l /dev/kvm`); if it is present, dev runs real KVM exactly like prod. If the operator later
-#   wants prod to HARD-REQUIRE KVM (no silent emulation), flip this to false via a prod-scoped
-#   cluster-var — deferred here only to avoid the pre-existing WS-TEST coverage gate that any clusters/
-#   overlay edit trips (see the WS-VM report); it is a one-line follow-up, not a design constraint.
+# VIRT MODE — use real KVM (nested) on this cluster:
+#   developerConfiguration.useEmulation was previously `true` on the belief that it "does NOT force
+#   emulation, KubeVirt still prefers KVM when /dev/kvm is present." That belief is EMPIRICALLY WRONG
+#   on KubeVirt v1.9 (WS-VM verified live): when useEmulation=true, virt-controller does NOT add the
+#   `devices.kubevirt.io/kvm` resource to the virt-launcher pod, so /dev/kvm is never mounted into the
+#   compute container and qemu ALWAYS falls back to software emulation (TCG) — even on nodes that
+#   advertise `devices.kubevirt.io/kvm=1k` and are fully CPU-labelled (`hypervisor=true`). Proof: on
+#   the dev cluster with useEmulation=true, `ls /dev/kvm` inside a virt-launcher compute container
+#   returned "No such file or directory" and the qemu accelerator was `tcg`. TCG guests are ~10x slow,
+#   never finish the in-guest conformance probes in time, and saturate node CPUs (a node went NotReady
+#   and its VMs were evicted -> VMI Failed).
+#     * false (set here) -> virt-controller REQUIRES + requests the kvm device, /dev/kvm is mounted,
+#                           and VMs run on real (nested) KVM. All three dev nodes have /dev/kvm
+#                           (advertised =1k, vmx/svm present), and prod mini-PCs have native KVM, so
+#                           this is safe cluster-wide. A node genuinely lacking /dev/kvm now fails LOUD
+#                           (correct — we want to know, not silently run 10x-slow emulated VMs).
+#     * true             -> the broken-on-1.9 behaviour above (silent TCG everywhere). Do NOT use while
+#                           the nodes have KVM.
+#   RUNBOOK STEP 1 remains: confirm `/dev/kvm` on a node (`virt-host-validate` / `ls -l /dev/kvm`).
 apiVersion: kubevirt.io/v1
 kind: KubeVirt
 metadata:
@@ -29,8 +34,9 @@ spec:
   # (Live migration across the 3 converged nodes is a nice-to-have per docs/06, not required.)
   configuration:
     developerConfiguration:
-      # Prefer real (nested) KVM; fall back to emulation ONLY when /dev/kvm is absent (see header).
-      useEmulation: true
+      # Use real (nested) KVM. `false` makes virt-controller REQUEST the kvm device so /dev/kvm is
+      # mounted into virt-launcher (KVM acceleration). `true` is broken on v1.9 -> silent TCG. (See header.)
+      useEmulation: false
     # Persistent EFI/TPM VM state (if a VM enables it) lands on the replicated Longhorn tier (ADR-0003),
     # inheriting the same durability as every other stateful volume.
     vmStateStorageClass: longhorn