## 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:
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.
## 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 :-)
## 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> ubuntu19. 04.qcow2< /name> 16106127360< /capacity> 16106127360< /allocation> lazy_refcounts/ >
<name>
<capacity>
<allocation>
<target>
<format type="qcow2"/>
<features>
<
</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. metadata` until a change [3] made it issue `preallocation= falloc` nowadays.
It used to use `preallocation=
eventual qemu-img call: metadata, compat= 1.1,lazy_ refcounts /var/lib/ libvirt/ images/ ubuntu18. 04.qcow2 15728640K` falloc, compat= 1.1,lazy_ refcounts /var/lib/ libvirt/ images/ live-server. qcow2 41943040K`
Old: `/usr/bin/qemu-img create -f qcow2 -o preallocation=
New: `/usr/bin/qemu-img create -f qcow2 -o preallocation=
## Version-Release number of selected component (if applicable): ##
v1.5 - v2.2.1
## How reproducible: ##
100%
## Steps to Reproduce: ## falloc
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=
## Actual results: ## falloc
qemu-img ... preallocation=
## Expected results: ## metadata (like in the past)
qemu-img ... preallocation=
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: ## capacity` ?
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<
* 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 /libvirt. org/formatstora ge.html# StorageVol /libvirt. org/git/ ?p=libvirt. git;a=blobdiff; f=src/storage/ storage_ util.c; h=897dfdaaee4da 967fb5dacc43274 84f40b8aa717; hp=b4aed0f7009b 8d7e81a64e4f4a5 c920a422fbba4; hb=c9ec7088c7a3 f4cd26bb471f1f2 43931fff6f4f9; hpb=c1bc9c662b4 11f8fa060719919 21a180480a0f40
[2]: https:/
[3]: https:/