Comment 7 for bug 1847105

With the older (pre 4.3) libvirt in place this creates it with metadata preallocation.

/usr/bin/qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts /var/lib/libvirt/images/ubuntu18.04.qcow2 15728640K

In the related code this looks like:
 834 if (info.size_arg > info.allocation)
 835 virBufferAddLit(&buf, "preallocation=metadata,");
 836 else
 837 virBufferAddLit(&buf, "preallocation=falloc,");

And size_arg == capacity (from xml).
Per definition [1] we have three cases for "allocation":
a) allocation can be bigger than capacity for high-metadata overhead cases
b) If allocation is omitted when creating a volume, the volume will be fully allocated at time of
   creation.
c) If set to a value smaller than the capacity, the pool has the option of deciding to sparsely
   allocate a volume.

But as we see in the XMLs above virt-manager asks to fully allocate. We hit neither of (a)/(b).
Therefore the pool has -NOT- the option to do a sparse allocation as we also do not hit (c)

It isn't written/defined explicitly in those statements, but our case of capacity==allocation should (form the text) behave like (b) at least in my reading. It didn't do so in the past and the libvirt change [2] fixed that unclarity.

I don't think we'd want to change libvirt to go back to not allocate in this case.
But we should report and ask at virt-manager if it should/want to submit a smaller allocation 0<=allocation<=capacity to get back to the old behavior.

virt-manager upstream then has a chance to agree and fix it (which we would backport) or discuss pointing to a different reading of [1] that would end up in a libvirt discussion and fix then.

[1]: https://libvirt.org/formatstorage.html#StorageVol
[2]: https://libvirt.org/git/?p=libvirt.git;a=commit;h=c9ec7088c7a3f4cd26bb471f1f243931fff6f4f9