diff --git a/apps/kubevirt-vms/ci1.yaml b/apps/kubevirt-vms/ci1.yaml
index 84a9f7c..7058f72 100644
--- a/apps/kubevirt-vms/ci1.yaml
+++ b/apps/kubevirt-vms/ci1.yaml
@@ -411,16 +411,24 @@ spec:
             # Confirmed via debug pod: PVC content IS a real bootable ISO9660
             # (file: "ISO 9660 CD-ROM filesystem data ... (bootable)"), so the
             # only bug was boot priority.
-            # 2026-05-08 PM: cdrom bus is SCSI (virtio-scsi controller). Bus
-            # choice is no longer load-bearing since the ISO is delivered via
-            # containerDisk (see volumes block below) — both SATA and SCSI
-            # work fine when the cdrom backing isn't a slow PVC. SCSI is kept
-            # because it's the modern bus and matches the standard FC
-            # KubeVirt VM template.
+            # 2026-05-08 PM: ISO presented as a virtio-blk DISK (not cdrom).
+            # Both SATA and SCSI cdrom buses hit OVMF BdsDxe "starting Boot0001
+            # ... Time out" regardless of storage backend (NFS, Longhorn PVC,
+            # containerDisk tmpfs — all rule out IO speed). The qemu cdrom
+            # emulation path appears to have a deep-seated read window issue
+            # under KubeVirt v1.4.0's OVMF firmware.
+            #
+            # Workaround: present the ISO bytes as a regular virtio-blk disk
+            # (model="virtio-non-transitional"). UEFI/OVMF still recognizes
+            # ISO9660 + El Torito boot records on a regular disk, so it can
+            # boot the EFI bootloader the same way it would from a USB stick.
+            # This is also closer to the FlowerCore.Distribution USB-key
+            # pattern: the ISO bytes live on a block device, UEFI boots from
+            # the GPT/El Torito boot record, Windows installer runs.
             - name: windows-iso
               bootOrder: 1
-              cdrom:
-                bus: scsi
+              disk:
+                bus: virtio
             - name: rootdisk
               bootOrder: 2
               disk: