Description of problem: Kubevirt plans to integrate libguestfs. The build setup uses bazel to build the container images, and this requires a fixed appliance. The appliance is extracted and copy into the container image layer. The root filesystem is a sparse file, and it makes the image size very large 5.59GB. A better option would be to use qcow2 format for the root. However, the current libguestfs explicitly set raw for the root. It will be very useful to have a way to be able to use qcow2 format for the root filesystem Version-Release number of selected component (if applicable): libguestfs 1.44 How reproducible: Always Steps to Reproduce: 1. Extract the libguestfs appliance 2. Build a container image with the extracted appliance 3. Verify the image size Additional info: The original problem can be found at https://github.com/kubevirt/kubevirt/pull/5402
The request here is to use the build option: ./configure --enable-appliance-format-auto This changes the way libguestfs opens the appliance by not forcing the root disk to be in raw format. The exact changes are: https://github.com/libguestfs/libguestfs/blob/e68a844eb406f0b32cc2c4e60ca66bc1a7f94bdc/lib/launch-direct.c#L641 https://github.com/libguestfs/libguestfs/blob/e68a844eb406f0b32cc2c4e60ca66bc1a7f94bdc/lib/launch-libvirt.c#L497 Because we don't force raw format, this makes it possible to construct a qcow2-based fixed appliance, which works around the problems that containers have preserving sparseness. For libguestfs in Fedora we will of course continue to use a supermin-built appliance in raw format. I wanted to see if this would have any overhead on the ordinary (raw) case. On my own system, without the option: $ ./run hyperfine -w 3 'guestfish -a /dev/null run' Benchmark #1: guestfish -a /dev/null run Time (mean ± σ): 1.601 s ± 0.015 s [User: 18.3 ms, System: 19.6 ms] Range (min … max): 1.580 s … 1.625 s 10 runs With the option: $ ./run hyperfine -w 3 'guestfish -a /dev/null run' Benchmark #1: guestfish -a /dev/null run Time (mean ± σ): 1.596 s ± 0.023 s [User: 16.5 ms, System: 21.3 ms] Range (min … max): 1.570 s … 1.647 s 10 runs This is well within error bars so I'm not worried from that point of view.
FEDORA-2021-a937a48cdd has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a937a48cdd
FEDORA-2021-a937a48cdd has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a937a48cdd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a937a48cdd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a937a48cdd has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.