fix(ci1): mount Windows ISO via Synology NFS (Path B for SATA-CDROM timeout)

Previous fix attempts confirmed the Longhorn-backed Filesystem PVC contains a perfectly valid bootable ISO9660 image. The bug is that SATA-CDROM emulation reading from a Longhorn Filesystem PVC is too slow for OVMF's boot read window — DVD-ROM enumeration times out before the bootloader loads. Symptom on the serial console: BdsDxe: failed to start Boot0001 "UEFI QEMU DVD-ROM QM00001 " ... Time out BdsDxe: No bootable option or device was found Block-mode PVC (Path A) was attempted and would likely fix the timing, but CDI v1.65.0's upload-target pod cannot open the underlying block device (runAsUser:107 + capabilities.drop:[ALL]): blockdev: cannot open /dev/cdi-block-volume: Permission denied Path B (this change): mount the ISO directly from Synology NAS over NFSv4.1. Bypasses both the Longhorn slowness and the CDI permission issue. QEMU's SATA emulator reads at native LAN speed. Layout: /volume1/ISOs/ — existing Synology export, RKE2 ACL already granted /volume1/ISOs/win2025-iso-disk/disk.img — new subdir, hardlink to the ISO file, named so KubeVirt's launcher finds it at the PV root A hardlink (not symlink) is required because symlinks with relative targets pointing to the parent directory are broken when the NFS PV sub-mounts the subdir as its root. Validated 2026-05-08 from rke2-server, rke2-agent1, rke2-agent2: mount -t nfs -o nfsvers=4.1,ro 10.0.58.3:/volume1/ISOs/win2025-iso-disk file disk.img -> ISO 9660 CD-ROM filesystem data ... (bootable) The original Longhorn Filesystem ISO PVC is RETAINED unused (so ArgoCD doesn't prune the populated PVC and so we have a fallback). Can be removed in a follow-up commit after the NFS path is proven on a successful Windows install. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-08 17:03:42 -05:00
parent ba18c52130
commit fc2aca0e9e
2 changed files with 117 additions and 1 deletions
--- a/apps/kubevirt-vms/ci1.yaml
+++ b/apps/kubevirt-vms/ci1.yaml
@@ -6,6 +6,14 @@
 # `bluejay-ws-sandbox-1` runner placeholder. Andrew explicitly does NOT want
 # BLUEJAY-WS registered as a runner (workstation has personal/operator state).
 #
+# Storage layout (2026-05-08):
+#   * ISO is now sourced from Synology NFS (Path B) — see
+#     win2025-iso-nfs-pv.yaml. The Longhorn Filesystem PVC
+#     `windows-server-2025-iso` below is RETAINED but UNUSED so the prior
+#     CDI upload state is preserved as a fallback (and so ArgoCD doesn't
+#     prune it on this commit). It can be deleted in a follow-up commit
+#     after the NFS path is proven on a successful Windows install.
+#
 # Status (2026-05-08): LIVE — Phase 1 prereqs satisfied:
 #   * Multus CNI v4.2.2 thick-plugin DaemonSet running on all 3 RKE2 nodes
 #     (apps/multus/multus.yaml; ApplicationSet `infra-multus` Synced/Healthy)
@@ -422,8 +430,17 @@ spec:
          persistentVolumeClaim:
            claimName: ci1-rootdisk
        - name: windows-iso
+          # Path B (2026-05-08): mount ISO from Synology NFS instead of
+          # Longhorn Filesystem PVC. The Filesystem-PVC path was confirmed to
+          # contain a valid bootable ISO9660 image but caused OVMF's
+          # SATA-CDROM read window to time out:
+          #   BdsDxe: failed to start Boot0001 ... Time out
+          # Block-mode DataVolume was attempted as Path A but blocked by CDI
+          # v1.65.0's upload pod capability drop. NFS-mounted ISO bypasses
+          # both issues. See win2025-iso-nfs-pv.yaml header for full rationale
+          # and Synology layout.
          persistentVolumeClaim:
-            claimName: windows-server-2025-iso
+            claimName: windows-server-2025-iso-nfs
        - name: virtio-drivers
          containerDisk:
            # Pinned to v1.8.2 (latest stable as of 2026-05-08).
--- a/apps/kubevirt-vms/win2025-iso-nfs-pv.yaml
+++ b/apps/kubevirt-vms/win2025-iso-nfs-pv.yaml
@@ -0,0 +1,99 @@
+# =============================================================================
+# Windows Server 2025 ISO — Static NFS PV (Path B for SATA-CDROM timeout)
+# =============================================================================
+# Purpose: Mount the ISO from Synology NAS via NFS instead of from a Longhorn-
+# backed Filesystem PVC.
+#
+# Why: SATA-CDROM emulation reading from a Longhorn-backed Filesystem PVC is
+# too slow for OVMF's boot read window — the DVD-ROM enumeration times out
+# before the bootloader can be read. Symptom on the serial console:
+#   BdsDxe: failed to start Boot0001 "UEFI QEMU DVD-ROM QM00001 " from ...
+#   BdsDxe: failed to start Boot0001 ... Time out
+#   BdsDxe: No bootable option or device was found
+# Diagnosis confirmed the ISO content is a perfectly valid bootable ISO9660
+# image — the bug is in the timing path between OVMF and Longhorn-backed
+# storage, not in the ISO itself.
+#
+# Block-mode PVC was tried (`volumeMode: Block` via DataVolume) and would
+# likely fix the timing, but CDI v1.65.0's upload-target pod cannot open the
+# block device due to runAsUser:107 + capabilities.drop:[ALL] and we got:
+#   blockdev: cannot open /dev/cdi-block-volume: Permission denied
+#
+# NFS-mounted ISO bypasses both issues: no Longhorn slowness, no CDI upload
+# pod permission concerns. The ISO is read directly from the NAS over a
+# native NFSv4.1 mount that QEMU's SATA emulator can read at full LAN speed.
+#
+# Layout on Synology:
+#   /volume1/ISOs/                                              (existing export, RKE2 ACL)
+#     en-us_windows_server_2025_updated_march_2026_x64_dvd_8e06425a.iso
+#     win2025-iso-disk/                                         (new subdir, 2026-05-08)
+#       disk.img -> hardlink to ../en-us_windows_server_2025_..._8e06425a.iso
+#
+# KubeVirt's launcher pod expects a PVC mounted at
+# /var/run/kubevirt-private/vmi-disks/<diskName>/disk.img — by mounting the
+# `win2025-iso-disk/` subdir as the NFS PV root, `disk.img` lives at the PV's
+# root and KubeVirt's CDROM emulator finds it without any path manipulation.
+#
+# A symlink would NOT work for sub-path NFS mounts (the relative target
+# `../...iso` falls outside the sub-mount root). A hardlink works because it
+# references the same inode regardless of mount point.
+#
+# Memory references:
+#   - feedback_synology_nfs_volume1_kubernetes_export_scoped (Synology export
+#     scoping pattern — but /volume1/ISOs export, unlike /volume1/kubernetes,
+#     does support sub-path mounts because Synology NFS is configured with
+#     pseudo-fs in NFSv4.1)
+#   - feedback_kubevirt_iso_first_install_bootorder_and_runstrategy (boot
+#     order / runStrategy gotchas, separate from the storage timing issue)
+#
+# Validation (2026-05-08, from rke2-server / rke2-agent1 / rke2-agent2):
+#   mount -t nfs -o nfsvers=4.1,ro 10.0.58.3:/volume1/ISOs/win2025-iso-disk /tmp/m
+#   file /tmp/m/disk.img
+#     -> ISO 9660 CD-ROM filesystem data 'SSS_X64FRE_EN-US_DV9' (bootable)
+# All 3 RKE2 nodes can mount and read.
+# =============================================================================
+
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: windows-server-2025-iso-nfs
+  labels:
+    flowercore.io/iso: windows-server-2025
+    flowercore.io/managed-by: bluejay-infra
+spec:
+  capacity:
+    storage: 8Gi
+  accessModes:
+    - ReadOnlyMany
+  volumeMode: Filesystem
+  persistentVolumeReclaimPolicy: Retain
+  storageClassName: ""              # static, no provisioner
+  mountOptions:
+    - nfsvers=4.1
+    - ro
+    - hard
+    - timeo=600
+    - retrans=3
+  nfs:
+    server: 10.0.58.3               # BlueJayNAS Synology DS1621+ on HOME VLAN 58
+    path: /volume1/ISOs/win2025-iso-disk
+    readOnly: true
+
+---
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: windows-server-2025-iso-nfs
+  namespace: kubevirt-vms
+  labels:
+    app: ci-runner
+    flowercore.io/managed-by: bluejay-infra
+spec:
+  accessModes:
+    - ReadOnlyMany
+  volumeMode: Filesystem
+  resources:
+    requests:
+      storage: 8Gi
+  storageClassName: ""
+  volumeName: windows-server-2025-iso-nfs