Launchpad has imported 3 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1759454.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2019-10-08T08:33:40+00:00 paelzer wrote: ## Description of problem: ## Hi, in Ubuntu bug 1847105 [1] I think I have found a somewhat unexpected or unclear behavior mismatch between libvirt `>v4.3` and virt-manager. For volume creation virt-manager since quite some time (I checked back until `v1.5`) will submit an XML like the following to libvirts volume creation: <volume> <name>ubuntu19.04.qcow2</name> <capacity>16106127360</capacity> <allocation>16106127360</allocation> <target> <format type="qcow2"/> <features> <lazy_refcounts/> </features> </target> </volume> The important detail in regard to this issues is that capacity==allocation. In the definition by libvirt [2] this is somewhat undefined. In my reading of it this case would also fully allocate the volume. But - and here is the change in behavior - up until libvirt 'v4.3' it didn't. It used to use `preallocation=metadata` until a change [3] made it issue `preallocation=falloc` nowadays. eventual qemu-img call: Old: `/usr/bin/qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts /var/lib/libvirt/images/ubuntu18.04.qcow2 15728640K` New: `/usr/bin/qemu-img create -f qcow2 -o preallocation=falloc,compat=1.1,lazy_refcounts /var/lib/libvirt/images/live-server.qcow2 41943040K` ## Version-Release number of selected component (if applicable): ## v1.5 - v2.2.1 ## How reproducible: ## 100% ## Steps to Reproduce: ## 1. create a new guest (use PXE to not require any ISO) 2. when you hit "Finish" to start the installation it will issue a qemu-img command 3. with newer libvirt versions this will use preallocation=falloc ## Actual results: ## qemu-img ... preallocation=falloc ## Expected results: ## qemu-img ... preallocation=metadata (like in the past) OR a statement that falloc is preferred by virt-manager as well and not just an accident due to a change in libvirt. ## Next steps: ## I was now wondering about virt-managers position on this, do you: * want to modify virt-manager to get back to spare/lazy allocations (TL;DR submit an allocation value that is `0<allocation<capacity`? * consider this change a bug in libvirt, so that we should report/change it there? Maybe the comparison there should be `>=` and not just `>` in your opinion? * not changing anything as the `falloc` creation is preferred from the POV of virt-manager * some other way answer I didn't predict :-) [1]: https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1847105 [2]: https://libvirt.org/formatstorage.html#StorageVol [3]: https://libvirt.org/git/?p=libvirt.git;a=blobdiff;f=src/storage/storage_util.c;h=897dfdaaee4da967fb5dacc4327484f40b8aa717;hp=b4aed0f7009b8d7e81a64e4f4a5c920a422fbba4;hb=c9ec7088c7a3f4cd26bb471f1f243931fff6f4f9;hpb=c1bc9c662b411f8fa06071991921a180480a0f40 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1847105/comments/10 ------------------------------------------------------------------------ On 2019-10-08T08:35:19+00:00 paelzer wrote: FYI: initially reported in https://github.com/virt-manager/virt- manager/issues/56 but then I realized that officially BZ is most likely the correct bug-tracker Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1847105/comments/11 ------------------------------------------------------------------------ On 2019-10-08T08:48:38+00:00 berrange wrote: This behaviour changed due to this commit: commit c9ec7088c7a3f4cd26bb471f1f243931fff6f4f9 Author: Wim ten Have <[email protected]> Date: Mon Apr 9 20:14:35 2018 +0200 storage: extend preallocation flags support for qemu-img This patch adds support to qcow2 formatted filesystem object storage by instructing qemu-img to build them with preallocation=falloc whenever the XML described storage <allocation> matches its <capacity>. For all other cases the filesystem stored objects are built with preallocation=metadata. Signed-off-by: Wim ten Have <[email protected]> Signed-off-by: Michal Privoznik <[email protected]> This is a semantic change, so should not have been allowed. It has been 1 & 1/2 years already, but I'm wondering if we should none the less revert it and instead add some other way to declare which preallocation strategy to use. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1847105/comments/13 ** Changed in: virt-manager Status: Unknown => Confirmed ** Changed in: virt-manager Importance: Unknown => Undecided -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847105 Title: very slow disk creation, snapshotting To manage notifications about this bug go to: https://bugs.launchpad.net/virt-manager/+bug/1847105/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
