From 84c9feb89357a48d75b6d11e322c6956c18f39be Mon Sep 17 00:00:00 2001
From: Codex <codex@openai.com>
Date: Fri, 8 May 2026 21:29:59 -0500
Subject: [PATCH] fix(ci1): present ISO as virtio-blk disk instead of cdrom
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

OVMF BdsDxe "starting Boot0001 ... Time out" persists across:
  - SATA cdrom + Longhorn Filesystem PVC (Path A)
  - SATA cdrom + Synology NFS (Path B failed: storage perms)
  - SCSI cdrom + Longhorn (Path B variant)
  - SCSI cdrom + containerDisk tmpfs (Path C)
  - + SecureBoot=false

That rules out: storage IO speed, cdrom bus type, signature
verification. Remaining cause is deeper in qemu's cdrom device
emulation under KubeVirt v1.4.0's OVMF firmware — the cdrom read
window for OVMF's first-sector probe is too short to satisfy from
the cdrom controller path regardless of bus type.

Workaround: present the ISO bytes as a regular virtio-blk DISK
(not a cdrom). UEFI/OVMF still recognizes ISO9660 + El Torito
boot records on any block device, so it can find and boot the
EFI bootloader the same way it would from a USB stick. virtio-blk
has a different read path that doesn't hit the cdrom-specific
timeout.

This also better aligns with the FlowerCore.Distribution USB-key
pattern: ISO bytes on a block device, UEFI boots from the El
Torito boot record, Windows installer takes over. The autounattend
ConfigMap (ci1-autounattend) drives unattended Windows setup once
the installer kicks off.

The containerDisk OCI image (localhost/win-server-2025:1.0)
remains unchanged — only the disk type in the VM spec changes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 apps/kubevirt-vms/ci1.yaml | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

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: