libvirt users - Jun 2018 - Re: Reintroduce "allocate entire disk" checkbox on virt-manager

Il 26-06-2018 23:49 Cole Robinson ha scritto:
> I see it as another test case and larger UI surface in the common path
> for something that will save clicks for a corner case. I still don't 
> see
> it asworth exposing in the UI.
> 
> - Cole
I can not force this decision, obviously. However, let me recap why I 
found it important to have the "allocate disk now" checkbox:

- RAW files, even sparse one, are faster than Qcow2 files in the long 
run (ie: when block allocation is >8 GB);
- Qcow2 snapshots have significant gotchas (ie: the guest is suspended 
during the snapshot), while using RAW files will at least prevent using 
virt-manager snapshot feature without thinking;
- on CoW filesystems, using Qcow2 files will means *double* CoW with a) 
reduced performance and b) more wear on SSDs;
- on filesystems not supporting fallocate, libvirtd reverts to "write 
zeroes to the entire file) which is both a) very slow and b) detrimental 
to SSDs life;
- most other virtualization platform (old virt-manager and current oVirt 
included) split the choice of file format from the allocation policy.

I 100% agree that, using the custom disk creation mask, what I ask it 
entirely possible with virt-manager today. However, it would be *very* 
handy to have the checkbox back in the VM wizard itself.

Would opening a BZ ticket at least reopen the possibility to reconsider 
that decision?
Thanks anyway.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

On Thu, Jun 28, 2018 at 12:35:56PM +0200, Gionatan Danti
wrote:
> Il 26-06-2018 23:49 Cole Robinson ha scritto:
> > I see it as another test case and larger UI surface in the common path
> > for something that will save clicks for a corner case. I still
don't see
> > it asworth exposing in the UI.
> > 
> > - Cole
> 
> I can not force this decision, obviously. However, let me recap why I found
> it important to have the "allocate disk now" checkbox:
> 
> - RAW files, even sparse one, are faster than Qcow2 files in the long run
> (ie: when block allocation is >8 GB);
There is always a performance distinction between raw and qcow2, but it is
much less these days with qcow2v3 than it was with the original qcow2
design. 
> - Qcow2 snapshots have significant gotchas (ie: the guest is suspended
> during the snapshot), while using RAW files will at least prevent using
> virt-manager snapshot feature without thinking;
This is really tangential. virt-manager chose to use internal snapshots
because they were easy to support, but it could equally use external
snapshots. This shouldn't have a bearing on other choices - if the
internal snapshotting is unacceptable due to the guest pause, this
needs addressing regardless of allocation.
> - on CoW filesystems, using Qcow2 files will means *double* CoW with a)
> reduced performance and b) more wear on SSDs;
Using qcow2 doesn't require you to use cow at the disk image layer - it
simply gives you the ability, should you want to. So you don't get double
cow by default
> - on filesystems not supporting fallocate, libvirtd reverts to "write
zeroes
> to the entire file) which is both a) very slow and b) detrimental to SSDs
> life;
Which widely used modern filesystems still don't support fallocate. It is
essentially a standard feature on any modern production quality filesystem 
these days.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Il 28-06-2018 12:44 Daniel P. Berrangé ha scritto:
> There is always a performance distinction between raw and qcow2, but it 
> is
> much less these days with qcow2v3 than it was with the original qcow2
> design.
Sure, but especially with random reads/writes over large LBA range the 
difference is noticeable [1]. Moreover, if something goes wrong, a RAW 
file can be inspected with standard block device tools. As a reference 
point, both oVirt and RHEL uses RAW files for base disk images.

It's not only performance related, but it regards thin-provision also. 
Why the wizard should automatically select fat provisioning based on 
image format? What if I want thin-provisioning using filesystem's sparse 
file support via RAW files?
> This is really tangential. virt-manager chose to use internal snapshots
> because they were easy to support, but it could equally use external
> snapshots. This shouldn't have a bearing on other choices - if the
> internal snapshotting is unacceptable due to the guest pause, this
> needs addressing regardless of allocation.
I agree, but currently the wizard force you to do a choice between:
a) sparse Qcow2 file, with (sometime dangerous?) internal snapshot 
support;
b) fully allocated RAW files, with *no* external snapshot support.
As you can see, it is virt-manager itself that entangles the choices 
regarding file format/allocation/snapshot support.
And external snapshot support in virt-manager would be *super* cool ;)
> Using qcow2 doesn't require you to use cow at the disk image layer - it
> simply gives you the ability, should you want to. So you don't get 
> double
> cow by default
I badly expressed the idea, sorry. Writing to a *snapshotted* Qcow2 file 
causes double CoW; on the other hand, writing to an un-snapshotted Qcow2 
file only causes double block allocation.
> Which widely used modern filesystems still don't support fallocate. It 
> is
> essentially a standard feature on any modern production quality 
> filesystem
> these days.
True, with an exception: ZFS. And it is a *big* exception. Moreover, why 
allocate all data by default when using RAW files? What about thin 
images?

What really strikes me is that the checkbox *was* here in previous 
virt-manager releases. Did it caused confusion or some other problems?

Thanks.

[1] https://www.linux-kvm.org/images/9/92/Qcow2-why-not.pdf

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8