# =============================================================================
# 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