[virt-tools-list] Storage image files and permissions

[Vincenzo Romano]

Il giorno mer 28 nov 2018 alle ore 14:41 Eric Blake
<eblake at redhat.com> ha scritto:
>
> On 11/28/18 2:29 AM, Vincenzo Romano wrote:
>
> >>> How do you request qcow3? According to the edit history of https://
> >>> wiki.qemu.org/Features/Qcow3 , qcow3 should be many years old but the manpage
> >>> of qemu-img on my current system does not mention qcow3.
> >>
> >> You probably mean qcow2v3. It is also spelled as 'qemu-img create -o
> >> compat=1.1' (newer qemu-img also recognizes the spelling compat=v3), as
> >> opposed to the older 'qemu-img create -o compat=0.10' or v2 images.  But
> >> if the virt-manager gui is specifically calling it qcow3, rather than
> >> qcow2v3, then that's a needless confusion that we should fix in the gui.
> >
> > Hi.
> > I relied on the "file" tool provided by Archlinux. It says "QCOW3" as
> > the file type by its contents.
>
> No, it says "QCOW Image (v3)", and means qcow2v3, because file is not
> distinguishing between 'qcow' and 'qcow2'.  It would be worth a bug
> report to the 'file' database maintainers to update their magic file to
> distinguish 'qcow' (the old v1 that is no longer used anywhere) from
> 'qcow2' (with both 'qcow2 v2' and 'qcow2 v3' flavors).

Understood. Thanks for the insight.

> > So I have manually created another storage image file by command line with:
> >
> > qemu-img create -f qcow2 ./windows2008-d1.qcow 250G
> >
> > The other image file (the sparse one) has been created by virt-manager/libvirt.
>
> So virt-manager probably requested preallocation when it created the file.

I suspect so.

> > Then I have run these commands:
> >
> > ~ ls -l
> > total 2,9G
> > drwxrwx--- 2 vmanager     vmanager   62 2018-11-27 13:14:36 .
> > drwxr-xr-x 7 vmanager     vmanager  152 2018-11-26 12:47:06 ..
> > -rw-rw---- 1 libvirt-qemu kvm      6,1G 2018-11-28 09:19:22 ubuntu18.04
> > -rw-rw---- 1 libvirt-qemu kvm      196K 2018-11-27 13:14:36 windows2008-d1.qcow
> > [root at host01 /home/vmanager/storage] file *
> > ubuntu18.04:         QEMU QCOW Image (v3), 6442450944 bytes
> > windows2008-d1.qcow: QEMU QCOW Image (v3), 268435456000 bytes
> > ~ du *
> > 3015704 ubuntu18.04
> > 196     windows2008-d1.qcow
> >
> > Both files have the same type but while "ubuntu18.04" is clearly a
> > sparse file, "windows2008-d1.qcow" is not.
>
> You've got that backwards. ubuntu18.04 is sized to use 6.1G of host
> space while providing 6G of data to the guest, so it is preallocated and
> does not appear to be sparse (although du would let you know if the file
> has holes as part of its preallocated space, such that the host size is
> large but the on-disk usage is still sparse).  windows2008-d1.qcow is
> occupying very little host space, while advertising 250G to the guest,
> so it is DEFINITELY sparse.

Hmmm... I think I don't agree-

The file "ubuntu18.04" is said to be 6.1GB while actually eating
3015704 kB (~ 3GB) in the file system.
It's a sparse file, indeed.

The file "windows2008-d1.qcow" is said to be 196 kB and that's the
actual room used on the file system.
That's NOT a sparse file. It's the usual QCOW file I am accustomed
with that grows both in file size and in storage eaten.
I think the former is a "somewhat special" QCOW file.

> > I doesn't make any real difference. It just puzzles me.
>
> The difference is whether you choose to preallocate an image. There are
> performance tradeoffs for doing so (a preallocated image is faster than
> a sparse one when it comes to writing to previously unused portions of
> the disk, but occupies more host space as a result - also, a
> preallocated image tends to have less fragmentation and less chance of
> hitting ENOSPC).

Yes, but I've never seen (so far) a sparse QCOW file. After all, QCOW
was introduced also to let users
use file systems not supporting "sparse files".

-- 
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS