fix(ci1): revert ISO to Filesystem PVC; CDI v1.65.0 block-upload pod blocked by capability drop

The Block-mode DataVolume migration (commit 0bf47df) hit a CDI v1.65.0 limitation:
the upload-target pod runs as uid 107 with `capabilities.drop: [ALL]`, so it
cannot open the underlying block device:

  blockdev: cannot open /dev/cdi-block-volume: Permission denied
  Saving stream failed: Unable to transfer source data to target file:
  error determining if block device exists: exit status 1

Reverting to a Filesystem-mode PVC + virtctl image-upload pvc, which DID work
(uploaded the 7.7 GiB ISO with valid ISO9660 magic intact). Boot timeout is
unresolved (header docstring captures the open issue + 3 paths to revisit).

The bootOrder swap (1c4145a) and runStrategy migration (87a7d7c) stay landed —
those are correct improvements regardless of the volume-mode question.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

apps/kubevirt-vms/ci1.yaml

@@ -49,57 +49,49 @@ metadata:
     pod-security.kubernetes.io/enforce: privileged
 
 ---
-# ISO DataVolume — CDI manages an underlying PVC of the same name and exposes
+# ISO PVC — populated via CDI virtctl image-upload (CDI is now installed).
-# the upload-target pod once it's ready.
 #
-# **Why DataVolume + Block volumeMode** (vs the original `kind: PersistentVolumeClaim`
+# **Volume mode (2026-05-08 status):** Filesystem-mode PVC. A migration to
-# + virtctl image-upload pvc): a `volumeMode: Filesystem` PVC stores the upload
+# `volumeMode: Block` via DataVolume was attempted to address an OVMF SATA
-# as `/disk.img` on a mounted ext4. KubeVirt then exposes that file as a SATA
+# CDROM read timeout, but CDI v1.65.0's upload-target pod runs as uid 107
-# CDROM via QEMU. On 2026-05-08 this caused the OVMF UEFI firmware to fail
+# with `capabilities.drop: [ALL]` and cannot open the underlying block
-# Boot0001 with "Time out" reading the SATA CDROM, even with the install ISO
+# device (`blockdev: cannot open /dev/cdi-block-volume: Permission denied`).
-# at bootOrder:1 — see docs/infrastructure/feedback notes below. The ISO
+# Reverted to Filesystem PVC pending one of:
-# content WAS valid (`file` reported "ISO 9660 CD-ROM filesystem data ...
+#   - CDI deployment override granting CAP_SYS_RAWIO to upload pod
-# (bootable)"), but the QEMU SATA emulation over a Filesystem-PVC backing was
+#   - Pre-populated PVC via privileged init pod that dd's the ISO directly
-# too slow / mis-attached for OVMF's CDROM read window.
+#   - Migration to a different storage class that exposes block devices
+#     differently (e.g. iSCSI, where Longhorn's CSI mount path may behave
+#     differently)
 #
-# `volumeMode: Block` gives us a raw block device directly — KubeVirt attaches
+# Population workflow (this PVC, Filesystem mode):
-# it to the VM as `/dev/sdX` style storage, OVMF reads ISO9660 sectors directly
+#   1. virtctl --kubeconfig $env:USERPROFILE\.kube\rke2.yaml image-upload pvc \
-# from the underlying block volume, no QEMU virtual file emulation needed.
-# This is the recommended pattern for ISO install media on KubeVirt + Longhorn.
-#
-# Population workflow:
-#   1. After this DataVolume is applied, CDI creates the PVC and an
-#      upload-target pod. Wait for `phase: UploadReady`.
-#   2. From BLUEJAY-WS:
-#        kubectl --kubeconfig $env:USERPROFILE\.kube\rke2.yaml port-forward \
-#          -n cdi service/cdi-uploadproxy 8443:443 &
-#        virtctl --kubeconfig $env:USERPROFILE\.kube\rke2.yaml image-upload dv \
 #        windows-server-2025-iso -n kubevirt-vms \
 #        --image-path "$env:USERPROFILE\Downloads\en-us_windows_server_2025_updated_march_2026_x64_dvd_8e06425a.iso" \
-#          --uploadproxy-url https://localhost:8443 --insecure --no-create
+#        --size 10Gi --storage-class longhorn --access-mode ReadWriteOnce \
-#   (`--no-create` — the DV/PVC already exist, virtctl just streams bytes.)
+#        --uploadproxy-url https://localhost:8443 --insecure
-apiVersion: cdi.kubevirt.io/v1beta1
+#   (--uploadproxy-url uses port-forward in practice: `kubectl port-forward
-kind: DataVolume
+#   -n cdi service/cdi-uploadproxy 8443:443 &` first.)
+#
+# **Open boot issue:** even with the ISO at bootOrder:1, OVMF console showed:
+#   BdsDxe: starting Boot0001 "UEFI QEMU DVD-ROM QM00001 " from ... Sata(...)
+#   BdsDxe: failed to start Boot0001 ... Time out
+# Diagnosis confirmed PVC content IS a valid bootable ISO9660 image — the
+# timeout is in OVMF reading from the SATA-CDROM-backed-by-filesystem-PVC.
+# Block mode would likely fix it; see CDI permission issue above.
+apiVersion: v1
+kind: PersistentVolumeClaim
 metadata:
   name: windows-server-2025-iso
   namespace: kubevirt-vms
   labels:
     app: ci-runner
     flowercore.io/managed-by: bluejay-infra
-  annotations:
-    # Tell CDI not to "convert" — keep raw bytes so the underlying block device
-    # IS the ISO9660 sectors verbatim, not a QCOW2 wrap.
-    cdi.kubevirt.io/storage.contentType: kubevirt
 spec:
-  source:
-    upload: {}
-  pvc:
   accessModes:
     - ReadWriteOnce          # Bump to ReadOnlyMany after population for multi-VM use
   resources:
     requests:
       storage: 10Gi          # Server 2025 ISO is 7.7GB; 10Gi for headroom
-    volumeMode: Block        # CRITICAL — see header comment above
   storageClassName: longhorn
 
 ---
@@ -410,11 +402,8 @@ spec:
           persistentVolumeClaim:
             claimName: ci1-rootdisk
         - name: windows-iso
-          # Reference the DataVolume (defined above) — CDI creates the PVC of
+          persistentVolumeClaim:
-          # the same name with volumeMode: Block. The VMI controller blocks
+            claimName: windows-server-2025-iso
-          # VM start until DV phase is Succeeded (i.e. upload completed).
-          dataVolume:
-            name: windows-server-2025-iso
         - name: virtio-drivers
           containerDisk:
             # Pinned to v1.8.2 (latest stable as of 2026-05-08).