[Pkg-libvirt-maintainers] Bug#939488: virt-manager: Inconsistent and confusing options when creating new storage volumes

[Chris]

Package: virt-manager
Version: 1:2.0.0-3
Severity: normal

Dear Maintainer,

In step 4 of the "Create a new virtual machine" wizard, when the user accepts
the default "Create a disk image..." option, no options are presented for file
type or preallocation. Worse, the .qcow2 image created in this way seems to be
a non-sparse file whose 'real' and 'apparent' sizes both correspond to the full
quota entered in the wizard. (`ls -lh`, `ls -sh`, and `du -h` all report 21G
for an image created with the default 20G quota.) Is virt-manager quietly
overriding the `qemu-img create` preallocation default of 'metadata'?

The "Add a Storage Volume" dialog that launches from Connection Details →
Storage → Create new volume, on the other hand, offers an input field for
'Allocation' in GiB in addition to the field for 'Max Capacity'. This
'Allocation' field is zero by default, which results in a sparse file whose
'apparent' size corresponds to the full quota, but the 'real' size is roughly
equal to the size of the contents. (That is, on a brand new volume created from
this dialog by simply providing a filename and accepting all defaults, `ls -lh`
reports 21G, but `ls -sh` and `du -h` report 3.4M. Installing a minimal Debian
system in it brings the 'real' size up to ~2.5G with no significant change in
'apparent' size.)

I would expect both of virt-manager's paths to creating a new storage volume to
offer the same options, and I would definitely *not* expect that clicking
through and accepting the defaults would result in storage volumes with
different properties depending on which path I took.

Also, the input field for preallocation as a disk-space value seems confusing
in its own right. What command-line option does that correspond to? Wouldn't it
make more sense for both of these dialogs to offer a list corresponding to the
valid `qemu-img create` preallocation options for the selected image type (ie
'off', 'metadata', 'falloc' or 'full' for a .qcow2 file), with qemu-img's
default pre-selected (so 'metadata', in the case of a .qcow2 file)?

Cheers!



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0                               3.24.10-1
ii  gir1.2-gtk-vnc-2.0                           0.9.0-1.1+b1
ii  gir1.2-libosinfo-1.0                         1.6.0-1
ii  gir1.2-libvirt-glib-1.0                      1.0.0-1
ii  gir1.2-vte-2.91                              0.54.2-2
ii  librsvg2-common                              2.44.14-1
ii  python-requests                              2.21.0-1
ii  python3                                      3.7.3-1
ii  python3-dbus                                 1.2.10-1
ii  python3-gi                                   3.32.2-1
ii  python3-gi-cairo                             3.32.2-1
ii  python3-libvirt                              5.0.0-1
ii  virtinst                                     1:2.0.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-spiceclientglib-2.0  0.37-1
ii  gir1.2-spiceclientgtk-3.0   0.37-1
ii  libvirt-daemon-system       5.0.0-4.1

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1  0.18.7-1
ii  gnome-keyring    3.28.2-5
pn  python3-guestfs  <none>
pn  ssh-askpass      <none>
ii  virt-viewer      7.0-2

-- no debconf information