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

Il 19-06-2018 20:14 Cole Robinson ha scritto:
> If you change the disk image format from qcow2 to raw in
> Edit->Preferences, then new disk images are set to fully allocated raw.
> Check the image details with 'qemu-img info $filename' to confirm.
So I
> think by default we are doing what you want?
> 
> - Cole
Er, the point is that I would really like to have a *sparse* RAW image 
file. On older virt-manager, unchecking "allocate entire disk" was
what
I normally used. Auto-allocating all disk space without a mean to avoid 
that has two main drawbacks:
- you can't have sparse/thin volumes;
- allocating on a fallocate-less filesystem is excruciatingly slow and 
cause of unneeded wear on SSDs.

Why using a sparse RAW image rather than a Qcow2 image? Basically:
- RAW disks are easier to handle/inspect in case something goes wrong;
- avoid double CoW on CoW-enabled filesystems (eg: ZFS, btrfs);
- better performance (no Qcow2 L2 chunk cache range, etc).

It is worth nothing that oVirt (and RHEV) uses (sparse or allocated, 
based on user selection) base RAW files with eventual Qcow2 overlays for 
snapshots.

Thanks.

-- 
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 06/19/2018 03:37 PM, Gionatan Danti wrote:
> Il 19-06-2018 20:14 Cole Robinson ha scritto:
>> If you change the disk image format from qcow2 to raw in
>> Edit->Preferences, then new disk images are set to fully allocated
raw.
>> Check the image details with 'qemu-img info $filename' to
confirm. So I
>> think by default we are doing what you want?
>>
>> - Cole
> 
> Er, the point is that I would really like to have a *sparse* RAW image
> file. On older virt-manager, unchecking "allocate entire disk"
was what
> I normally used. Auto-allocating all disk space without a mean to avoid
> that has two main drawbacks:
> - you can't have sparse/thin volumes;
> - allocating on a fallocate-less filesystem is excruciatingly slow and
> cause of unneeded wear on SSDs.
> 
> Why using a sparse RAW image rather than a Qcow2 image? Basically:
> - RAW disks are easier to handle/inspect in case something goes wrong;
> - avoid double CoW on CoW-enabled filesystems (eg: ZFS, btrfs);
> - better performance (no Qcow2 L2 chunk cache range, etc).
> 
> It is worth nothing that oVirt (and RHEV) uses (sparse or allocated,
> based on user selection) base RAW files with eventual Qcow2 overlays for
> snapshots.
> 
Sorry, I misunderstood. You can still achieve what you want but it's
more clicks: new vm, manage storage, add volume, and select raw volume
with whatever capacity you want but with 0 allocation.

qcow2 is the default for virt-manager because it enables features like
snapshots out of the box. The main motivation I have largely heard for
wanting raw over qcow2 is performance, but then using sparse raw
actually makes raw less performant, so it's kind of a weird middle
ground. For that reason I don't think it warrants adding back the
checkbox to the new VM UI since I think it's a fairly obscure use case,
and it can be achieved through the 'manage storage' wizard albeit with
more clicks

- Cole

Il 19-06-2018 22:16 Cole Robinson ha scritto:
> Sorry, I misunderstood. You can still achieve what you want but it's
> more clicks: new vm, manage storage, add volume, and select raw volume
> with whatever capacity you want but with 0 allocation.
Sure, but the automatic disk creation is very handy and much less error 
prone.
As it is now, if using a fallocate-less filesystem (eg: ZFS) and *not* 
selecting to create a custom disk, you risk waiting minutes or hours for 
libvirt to fully allocate the image by writing 0s to the disk file. This 
can wreck havok on SSDs and other eundurance-limited medium.
> qcow2 is the default for virt-manager because it enables features like
> snapshots out of the box. The main motivation I have largely heard for
> wanting raw over qcow2 is performance, but then using sparse raw
> actually makes raw less performant, so it's kind of a weird middle
> ground. For that reason I don't think it warrants adding back the
> checkbox to the new VM UI since I think it's a fairly obscure use case,
> and it can be achieved through the 'manage storage' wizard albeit
with
> more clicks
> 
> - Cole
On CoW filesystems, sparse RAW files are faster then Qcow2 ones. 
Moreover, avoiding double CoW is important for SSDs (which have limited 
lifespan). Even on XFS, sparse RAW files should be faster in the long 
run than Qcow2 files, due to no weird limitation on L2 chunk cache size.

I found the checkbox quite self-explanatory and very handy. Any chances 
to reconsider your decision?
Thanks.

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