fix(ci1): revert ISO to Filesystem PVC; CDI v1.65.0 block-upload pod blocked by capability drop
The Block-mode DataVolume migration (commit0bf47df) hit a CDI v1.65.0 limitation: the upload-target pod runs as uid 107 with `capabilities.drop: [ALL]`, so it cannot open the underlying block device: blockdev: cannot open /dev/cdi-block-volume: Permission denied Saving stream failed: Unable to transfer source data to target file: error determining if block device exists: exit status 1 Reverting to a Filesystem-mode PVC + virtctl image-upload pvc, which DID work (uploaded the 7.7 GiB ISO with valid ISO9660 magic intact). Boot timeout is unresolved (header docstring captures the open issue + 3 paths to revisit). The bootOrder swap (1c4145a) and runStrategy migration (87a7d7c) stay landed — those are correct improvements regardless of the volume-mode question. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Codex
@@ -49,58 +49,50 @@ metadata:
|
|||||||
pod-security.kubernetes.io/enforce: privileged
|
pod-security.kubernetes.io/enforce: privileged
|
||||||
|
|
||||||
---
|
---
|
||||||
# ISO DataVolume — CDI manages an underlying PVC of the same name and exposes
|
# ISO PVC — populated via CDI virtctl image-upload (CDI is now installed).
|
||||||
# the upload-target pod once it's ready.
|
|
||||||
#
|
#
|
||||||
# **Why DataVolume + Block volumeMode** (vs the original `kind: PersistentVolumeClaim`
|
# **Volume mode (2026-05-08 status):** Filesystem-mode PVC. A migration to
|
||||||
# + virtctl image-upload pvc): a `volumeMode: Filesystem` PVC stores the upload
|
# `volumeMode: Block` via DataVolume was attempted to address an OVMF SATA
|
||||||
# as `/disk.img` on a mounted ext4. KubeVirt then exposes that file as a SATA
|
# CDROM read timeout, but CDI v1.65.0's upload-target pod runs as uid 107
|
||||||
# CDROM via QEMU. On 2026-05-08 this caused the OVMF UEFI firmware to fail
|
# with `capabilities.drop: [ALL]` and cannot open the underlying block
|
||||||
# Boot0001 with "Time out" reading the SATA CDROM, even with the install ISO
|
# device (`blockdev: cannot open /dev/cdi-block-volume: Permission denied`).
|
||||||
# at bootOrder:1 — see docs/infrastructure/feedback notes below. The ISO
|
# Reverted to Filesystem PVC pending one of:
|
||||||
# content WAS valid (`file` reported "ISO 9660 CD-ROM filesystem data ...
|
# - CDI deployment override granting CAP_SYS_RAWIO to upload pod
|
||||||
# (bootable)"), but the QEMU SATA emulation over a Filesystem-PVC backing was
|
# - Pre-populated PVC via privileged init pod that dd's the ISO directly
|
||||||
# too slow / mis-attached for OVMF's CDROM read window.
|
# - Migration to a different storage class that exposes block devices
|
||||||
|
# differently (e.g. iSCSI, where Longhorn's CSI mount path may behave
|
||||||
|
# differently)
|
||||||
#
|
#
|
||||||
# `volumeMode: Block` gives us a raw block device directly — KubeVirt attaches
|
# Population workflow (this PVC, Filesystem mode):
|
||||||
# it to the VM as `/dev/sdX` style storage, OVMF reads ISO9660 sectors directly
|
# 1. virtctl --kubeconfig $env:USERPROFILE\.kube\rke2.yaml image-upload pvc \
|
||||||
# from the underlying block volume, no QEMU virtual file emulation needed.
|
# windows-server-2025-iso -n kubevirt-vms \
|
||||||
# This is the recommended pattern for ISO install media on KubeVirt + Longhorn.
|
# --image-path "$env:USERPROFILE\Downloads\en-us_windows_server_2025_updated_march_2026_x64_dvd_8e06425a.iso" \
|
||||||
|
# --size 10Gi --storage-class longhorn --access-mode ReadWriteOnce \
|
||||||
|
# --uploadproxy-url https://localhost:8443 --insecure
|
||||||
|
# (--uploadproxy-url uses port-forward in practice: `kubectl port-forward
|
||||||
|
# -n cdi service/cdi-uploadproxy 8443:443 &` first.)
|
||||||
#
|
#
|
||||||
# Population workflow:
|
# **Open boot issue:** even with the ISO at bootOrder:1, OVMF console showed:
|
||||||
# 1. After this DataVolume is applied, CDI creates the PVC and an
|
# BdsDxe: starting Boot0001 "UEFI QEMU DVD-ROM QM00001 " from ... Sata(...)
|
||||||
# upload-target pod. Wait for `phase: UploadReady`.
|
# BdsDxe: failed to start Boot0001 ... Time out
|
||||||
# 2. From BLUEJAY-WS:
|
# Diagnosis confirmed PVC content IS a valid bootable ISO9660 image — the
|
||||||
# kubectl --kubeconfig $env:USERPROFILE\.kube\rke2.yaml port-forward \
|
# timeout is in OVMF reading from the SATA-CDROM-backed-by-filesystem-PVC.
|
||||||
# -n cdi service/cdi-uploadproxy 8443:443 &
|
# Block mode would likely fix it; see CDI permission issue above.
|
||||||
# virtctl --kubeconfig $env:USERPROFILE\.kube\rke2.yaml image-upload dv \
|
apiVersion: v1
|
||||||
# windows-server-2025-iso -n kubevirt-vms \
|
kind: PersistentVolumeClaim
|
||||||
# --image-path "$env:USERPROFILE\Downloads\en-us_windows_server_2025_updated_march_2026_x64_dvd_8e06425a.iso" \
|
|
||||||
# --uploadproxy-url https://localhost:8443 --insecure --no-create
|
|
||||||
# (`--no-create` — the DV/PVC already exist, virtctl just streams bytes.)
|
|
||||||
apiVersion: cdi.kubevirt.io/v1beta1
|
|
||||||
kind: DataVolume
|
|
||||||
metadata:
|
metadata:
|
||||||
name: windows-server-2025-iso
|
name: windows-server-2025-iso
|
||||||
namespace: kubevirt-vms
|
namespace: kubevirt-vms
|
||||||
labels:
|
labels:
|
||||||
app: ci-runner
|
app: ci-runner
|
||||||
flowercore.io/managed-by: bluejay-infra
|
flowercore.io/managed-by: bluejay-infra
|
||||||
annotations:
|
|
||||||
# Tell CDI not to "convert" — keep raw bytes so the underlying block device
|
|
||||||
# IS the ISO9660 sectors verbatim, not a QCOW2 wrap.
|
|
||||||
cdi.kubevirt.io/storage.contentType: kubevirt
|
|
||||||
spec:
|
spec:
|
||||||
source:
|
accessModes:
|
||||||
upload: {}
|
- ReadWriteOnce # Bump to ReadOnlyMany after population for multi-VM use
|
||||||
pvc:
|
resources:
|
||||||
accessModes:
|
requests:
|
||||||
- ReadWriteOnce # Bump to ReadOnlyMany after population for multi-VM use
|
storage: 10Gi # Server 2025 ISO is 7.7GB; 10Gi for headroom
|
||||||
resources:
|
storageClassName: longhorn
|
||||||
requests:
|
|
||||||
storage: 10Gi # Server 2025 ISO is 7.7GB; 10Gi for headroom
|
|
||||||
volumeMode: Block # CRITICAL — see header comment above
|
|
||||||
storageClassName: longhorn
|
|
||||||
|
|
||||||
---
|
---
|
||||||
# Root disk PVC — empty 200Gi volume that Windows installs into.
|
# Root disk PVC — empty 200Gi volume that Windows installs into.
|
||||||
@@ -410,11 +402,8 @@ spec:
|
|||||||
persistentVolumeClaim:
|
persistentVolumeClaim:
|
||||||
claimName: ci1-rootdisk
|
claimName: ci1-rootdisk
|
||||||
- name: windows-iso
|
- name: windows-iso
|
||||||
# Reference the DataVolume (defined above) — CDI creates the PVC of
|
persistentVolumeClaim:
|
||||||
# the same name with volumeMode: Block. The VMI controller blocks
|
claimName: windows-server-2025-iso
|
||||||
# VM start until DV phase is Succeeded (i.e. upload completed).
|
|
||||||
dataVolume:
|
|
||||||
name: windows-server-2025-iso
|
|
||||||
- name: virtio-drivers
|
- name: virtio-drivers
|
||||||
containerDisk:
|
containerDisk:
|
||||||
# Pinned to v1.8.2 (latest stable as of 2026-05-08).
|
# Pinned to v1.8.2 (latest stable as of 2026-05-08).
|
||||||
|
|||||||
Reference in New Issue
Block a user