Repository navigation
feat(qemu): back the guest boot image with an overlay by default - #215
Conversation
Coverage Report for CI Build 39980601444Coverage decreased (-0.001%) to 71.672%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
6e3d872 to
47491fc
Compare
47491fc to
4311383
Compare
naddinadja
left a comment
naddinadja
left a comment
There was a problem hiding this comment.
Single question, but otherwise it looks good! :)
| class FakeConfig: | ||
| def __init__(self, options): | ||
| self.options = options | ||
|
|
||
|
|
||
| class FakeCijoe: | ||
| """Records local commands; runs them for real when 'execute' is set""" |
There was a problem hiding this comment.
These "FakeConfig" and "FakeCijoe" - is that not something we've had use for in other tests? Sounds like either (a) something other tests could use, or (b) something we've solved in other ways in the existing tests?
There was a problem hiding this comment.
Good catch, (b): tests/core/test_transport_ssh.py in #214 uses a real Cijoe built from a real Config and fakes only the boundary, so this test now does the same, patching only run_local to record the commands, and the two fakes are gone (3dc33ea). tests/system_imaging/test_diskimage_from_oras.py still carries its own FakeCijoe; folding that one in is left for a separate change.
4311383 to
3dc33ea
Compare
|
xNVMe exercises this together with #214 and #216 in xnvme/xnvme#825, which pins cijoe to the preview branch |
guest_initialize copied the staged disk image to the guest's boot.img. For a large image that copy is a real cost: the 11.7 GiB qcow2 of a ROCm guest takes over a minute on a CI runner, which then throws the guest away, and every further guest from the same image pays it again, in time and in disk. boot.img is now a qcow2 overlay backed by the staged image, which takes no time, and several guests share one image, each holding only what it writes. That matches the split already there: system-imaging is the store of images, and a guest references one. The image must stay unchanged while a guest uses it. 'overlay: false' restores the copy, and diskimage_from_cloudimage asks for it, since it turns boot.img into the disk image afterwards. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Simon A. F. Lund <os@safl.dk>
The report options change landed before the 0.9.61 section existed, so its entry is added now that the section is there. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Simon A. F. Lund <os@safl.dk>
3dc33ea to
20c04eb
Compare
Makes the guest boot image a qcow2 overlay backed by the staged disk image, instead of a copy of it. System-imaging is the store of images, and a guest now references one, holding only what it writes. That saves the copy, over a minute for an 11.7 GiB image on a CI runner, and lets several guests share one image.
Worth a look: this is now the default, so every task using
qemu.guest_initializegets an overlay;overlay: falserestores the copy. The image must stay unchanged while a guest uses it.diskimage_from_cloudimageasks for the copy explicitly, because it turnsboot.imginto the disk image afterwards. nosi's owndiskimage_build.pyalso callsGuest.initialize()and will get an overlay, which is fine there: it resizesboot.imgand finishes withqemu-img convert -c, which reads through the backing file.Verification:
tests/qemu/test_guest_initialize.pycovers the default overlay, the copy, an absolute backing path given a relative disk path (qemu would read a relative one from the overlay's directory), and a real qcow2 overlay's backing file and size; the Linux unittest job now installsqemu-utilsso the last one runs there, while it skips on macOS. This repository's example jobs boot guests from overlays (qemu.guest_x86_64,qemu.guest_aarch64) and build disk images throughdiskimage_from_cloudimage(core.get_put,system_imaging.debian). On a physical host, xNVMe's full verify flow for its ROCm guest booted from the overlay, built xNVMe and SPDK in it, and passed 62 tests with 103 skipped, the same as with a copy; the overlay held 1.15 GiB of writes against an 11.7 GiB copy.