Tracing qemu-img calls when creating a new disk image from virt-manager:
Before change the qemu-img that libvirt emits due to the XML from virt-manager is:
$ /usr/bin/qemu-img create -f qcow2 -o preallocation=falloc,compat=1.1,lazy_refcounts /var/lib/libvirt/images/ubuntu20.04.qcow2 26214400K
And as we know from before, if you run that on ZFS that is slower than one would hope.
Trying the libvirt build from the PPA.
4 0 162200 142352 20 0 163100 5120 poll_s Sl ? 0:03 \_ /usr/bin/qemu-img create -f qcow2 -o preallocation=falloc,compat=1.1,lazy_refcounts /var/lib/libvirt/images/ubuntu20.04-b.qcow2 26214400K
That is still as slow since it is the same qemu-img call.
Despite [1] being applied.
Actually looking at it more critically
Let's check what happens in that function
break on virStorageBackendCreateQemuImgCmdFromVol in gdb with source and debug symbols from the PPA in place.
Thanks to the compiler we don't see a lot:
(gdb) p info
$1 = {format = <optimized out>, type = 0x7fb98e58bdbc "qcow2", inputType = <optimized out>, path = <optimized out>, size_arg = <optimized out>, allocation = <optimized out>,
encryption = <optimized out>, preallocate = <optimized out>, compat = <optimized out>, features = <optimized out>, nocow = <optimized out>, backingPath = <optimized out>,
backingFormat = <optimized out>, inputPath = <optimized out>, inputFormatStr = <optimized out>, inputFormat = <optimized out>, secretAlias = <optimized out>}
b virStorageBackendCreateQemuImgCmdFromVol
b storageBackendCreateQemuImgOpts
b storageBackendCreateQemuImgSetOptions
b ../../../src/storage/storage_util.c:712
712 if (info->preallocate) {
713 if (info->size_arg > info->allocation)
714 virBufferAddLit(&buf, "preallocation=metadata,");
715 else
716 virBufferAddLit(&buf, "preallocation=falloc,");
(gdb) p info->preallocate
$1 = <optimized out>
(gdb) p info->size_arg
$2 = <optimized out>
(gdb) p info->allocation
$3 = <optimized out>
Tracing qemu-img calls when creating a new disk image from virt-manager:
Before change the qemu-img that libvirt emits due to the XML from virt-manager is: falloc, compat= 1.1,lazy_ refcounts /var/lib/ libvirt/ images/ ubuntu20. 04.qcow2 26214400K
$ /usr/bin/qemu-img create -f qcow2 -o preallocation=
And as we know from before, if you run that on ZFS that is slower than one would hope.
Trying the libvirt build from the PPA. falloc, compat= 1.1,lazy_ refcounts /var/lib/ libvirt/ images/ ubuntu20. 04-b.qcow2 26214400K
4 0 162200 142352 20 0 163100 5120 poll_s Sl ? 0:03 \_ /usr/bin/qemu-img create -f qcow2 -o preallocation=
That is still as slow since it is the same qemu-img call.
Despite [1] being applied.
Actually looking at it more critically
Let's check what happens in that function ndCreateQemuImg CmdFromVol in gdb with source and debug symbols from the PPA in place.
break on virStorageBacke
Thanks to the compiler we don't see a lot:
(gdb) p info
$1 = {format = <optimized out>, type = 0x7fb98e58bdbc "qcow2", inputType = <optimized out>, path = <optimized out>, size_arg = <optimized out>, allocation = <optimized out>,
encryption = <optimized out>, preallocate = <optimized out>, compat = <optimized out>, features = <optimized out>, nocow = <optimized out>, backingPath = <optimized out>,
backingFormat = <optimized out>, inputPath = <optimized out>, inputFormatStr = <optimized out>, inputFormat = <optimized out>, secretAlias = <optimized out>}
b virStorageBacke ndCreateQemuImg CmdFromVol reateQemuImgOpt s reateQemuImgSet Options ./src/storage/ storage_ util.c: 712
b storageBackendC
b storageBackendC
b ../../.
712 if (info->preallocate) { (&buf, "preallocation= metadata, "); (&buf, "preallocation= falloc, ");
713 if (info->size_arg > info->allocation)
714 virBufferAddLit
715 else
716 virBufferAddLit
(gdb) p info->preallocate
$1 = <optimized out>
(gdb) p info->size_arg
$2 = <optimized out>
(gdb) p info->allocation
$3 = <optimized out>
Hrm, this needs an -O0 build or I'll go crazy
[1]: https:/ /libvirt. org/git/ ?p=libvirt. git;a=commit; h=81a3042a12c7c 06