diff --git a/apps/kubevirt-vms/ci1.yaml b/apps/kubevirt-vms/ci1.yaml
index 1a8daac..9fb54d4 100644
--- a/apps/kubevirt-vms/ci1.yaml
+++ b/apps/kubevirt-vms/ci1.yaml
@@ -49,32 +49,58 @@ metadata:
     pod-security.kubernetes.io/enforce: privileged
 
 ---
-# ISO PVC — populated via CDI virtctl image-upload (CDI is now installed).
-# Population workflow (LIVE 2026-05-08):
-#   1. virtctl --kubeconfig $env:USERPROFILE\.kube\rke2.yaml image-upload pvc \
-#        windows-server-2025-iso -n kubevirt-vms \
-#        --image-path "$env:USERPROFILE\Downloads\en-us_windows_server_2025_updated_march_2026_x64_dvd_8e06425a.iso" \
-#        --size 10Gi --storage-class longhorn --access-mode ReadWriteOnce \
-#        --uploadproxy-url https://cdi-uploadproxy.cdi.svc:443 --insecure
-#   (--uploadproxy-url uses port-forward in practice: see plan doc Phase 1.5.)
+# ISO DataVolume — CDI manages an underlying PVC of the same name and exposes
+# the upload-target pod once it's ready.
 #
-# Note: CDI's PVC creation hooks add cdi.kubevirt.io/storage.* annotations
-# automatically. The ISO source file is 7.7GB → request 10Gi for headroom.
-apiVersion: v1
-kind: PersistentVolumeClaim
+# **Why DataVolume + Block volumeMode** (vs the original `kind: PersistentVolumeClaim`
+# + virtctl image-upload pvc): a `volumeMode: Filesystem` PVC stores the upload
+# as `/disk.img` on a mounted ext4. KubeVirt then exposes that file as a SATA
+# CDROM via QEMU. On 2026-05-08 this caused the OVMF UEFI firmware to fail
+# Boot0001 with "Time out" reading the SATA CDROM, even with the install ISO
+# at bootOrder:1 — see docs/infrastructure/feedback notes below. The ISO
+# content WAS valid (`file` reported "ISO 9660 CD-ROM filesystem data ...
+# (bootable)"), but the QEMU SATA emulation over a Filesystem-PVC backing was
+# too slow / mis-attached for OVMF's CDROM read window.
+#
+# `volumeMode: Block` gives us a raw block device directly — KubeVirt attaches
+# it to the VM as `/dev/sdX` style storage, OVMF reads ISO9660 sectors directly
+# 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
+#   (`--no-create` — the DV/PVC already exist, virtctl just streams bytes.)
+apiVersion: cdi.kubevirt.io/v1beta1
+kind: DataVolume
 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:
-  accessModes:
-    - ReadWriteOnce          # Bump to ReadOnlyMany after population for multi-VM use
-  resources:
-    requests:
-      storage: 10Gi          # Bumped from 6Gi (Server 2025 ISO is 7.7GB)
-  storageClassName: longhorn
+  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
 
 ---
 # Root disk PVC — empty 200Gi volume that Windows installs into.
@@ -384,8 +410,11 @@ spec:
           persistentVolumeClaim:
             claimName: ci1-rootdisk
         - name: windows-iso
-          persistentVolumeClaim:
-            claimName: windows-server-2025-iso
+          # Reference the DataVolume (defined above) — CDI creates the PVC of
+          # the same name with volumeMode: Block. The VMI controller blocks
+          # 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).