New image allocation uses preallocation=falloc since libvirt 4.3 (instead of metadata)

[cpaelzer]

Hi,
in Ubuntu bug 1847105 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 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 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

This was found by users wondering about increased time when e.g. creating an image for a new guest.

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 :-)

[cpaelzer]

I beg your pardon, I have too late realized that you most likely prefer BZ.
I have opened it in https://bugzilla.redhat.com/show_bug.cgi?id=1759454 as well now.
Please feel free to close the one in the less preferred bug tracker.

[crobinso]

No worries