fc2aca0e9e
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>
100 lines
4.0 KiB
YAML
100 lines
4.0 KiB
YAML
# =============================================================================
|
|
# 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
|