- Shipped
- September 23, 2026 at 1:27 PM UTC
- Author
- Kamo
- Commit
- b9ff2a8
The job wrote the compressed qcow2 the build produces straight into the golden claim. KubeVirt attaches a Filesystem-PVC disk with <driver type='raw'> — always, it does not sniff the file — so qemu read a qcow2 as a raw disk. A qcow2 begins with its own header rather than a partition table, the firmware found nothing bootable, and the guest produced ZERO bytes of serial output. Every symptom pointed somewhere else. The DataVolume cloned to Succeeded 100%. The VirtualMachine reached Running with an IP on a node. The domain was type='kvm' on qemu-kvm, so it was not emulation. libvirt logged "Unable to open /dev/kvm: Permission denied", which is capability-probe noise the working platform desktop logs too. What actually happened was that the readiness probe on 3389 never passed, so the Service got no endpoints, so nothing could reach the agent on 9810, so the computer sat in WAKING until it timed out — and no step in that chain mentions the disk. The only honest signal was a serial log of exactly 0 bytes and a `qemu-img: exit status 1` line in the launcher. CDI's IMPORT path converts qcow2 to raw, which is why golden-datavolume.yaml can take a qcow2 over HTTP. A CDI CLONE copies the volume verbatim. Writing the image into the claim directly — which is what makes this build need no HTTP host and no upload credential — means doing the conversion that import would have done. `qemu-img convert -O raw -S 4k` rather than a cp, so it stays sparse: 20 GB declared, 4.1 GB stored for this build. The job now prints `qemu-img info` on the result, because the failure this fixes is invisible and the format is one line to check. build-golden-image.sh still produces a compressed qcow2 at $OUT. That is correct for the HTTP import path and a third the size; the conversion belongs where the raw requirement is, which is the claim.