[Users] Info on snapshot removal operations and final disk format

[Bob Doolittle]

On 11/16/2013 7:46 AM, Gianluca Cecchi wrote:
> Hello,
> I'm on oVirt 3.2.3-1 on a Fedora 18 all-in-one test server.
> I have a Windows XP VM that has a disk in qcow2 format and has a snapshot on it.
> When I delete the snapshot I see, from the commands intercepted, that
> the final effect is to have a raw disk (aka preallocated) .... is this
> correct and always true?

raw != preallocated. It can still be thin-provisioned. qcow2 is only
required for holding snapshots since effectively it can represent a
delta from some base image, but raw has better performance so is the
best format to use when no snapshots are present.

I believe the trick for thin-provisioning raw images is that Linux file 
systems (or the ones I'm aware of anyway) support "sparse" files, which 
means any block containing all zeros does not require backing storage 
and so in a sparse file it consumes no disk blocks.
See http://libguestfs.org/virt-sparsify.1.html, and
http://rwmj.wordpress.com/2010/10/19/tip-making-a-disk-image-sparse/

Note you cannot trust the output of ls -l for a sparse file.
Add the -s option. For example:

% truncate -s 10M /tmp/zeros
% ls -l /tmp/zeros
-rw-rw-r--. 1 rad rad 10485760 Nov 17 15:20 /tmp/zeros
% ls -ls /tmp/zeros
0 -rw-rw-r--. 1 rad rad 10485760 Nov 17 15:20 /tmp/zeros


The -s option shows us that no data blocks are in use, since it's a
completely sparse file.

If you've played with libvirt via Virtual Machine Manager you'll find
that you can select a "raw" disk format (default), and then select thin
provisioning with both a max allocation and a pre-allocation. This last
parameter unfortunately seems unavailable via the oVirt interface. It's
nice to say how much you'd like pre-allocated, so that you get better
initial performance when you know about how much you're going to need to
begin with. I'd love to see that in a future release.

-Bob

> Does this mean that even if I create a VM with thin provisioned disks,
> as soon as I take at least one snapshot and I then delete it I only
> have raw disks?
> Or am I missing anything?
>
> This what I observed:
> as soon as I launch delete snapshot operation:
>
> raw format of new disk
> vdsm     30805  1732  6 13:24 ?        00:00:00 /usr/bin/dd
> if=/dev/zero of=/rhev/data-center/65c9777e-23f1-4f04-8cea-e7c8871dc88b/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326_MERGE
> bs=1048576 seek=0 skip=0 conv=notrunc count=11264 oflag=direct
>
> after about 5 minutes:
> convert from qemu format to raw format
> vdsm     31287  1732  7 13:29 ?        00:00:08 /usr/bin/qemu-img
> convert -t none -f qcow2
> /rhev/data-center/65c9777e-23f1-4f04-8cea-e7c8871dc88b/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326
> -O raw /rhev/data-center/65c9777e-23f1-4f04-8cea-e7c8871dc88b/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326_MERGE
>
> at the end probably there is a rename of the disk file and
> qemu-img info /rhev/data-center/65c9777e-23f1-4f04-8cea-e7c8871dc88b/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326
>
> image: /rhev/data-center/65c9777e-23f1-4f04-8cea-e7c8871dc88b/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/d4fa7785-8a89-4d13-9082-52556ab0b326
> file format: raw
> virtual size: 11G (11811160064 bytes)
> disk size: 9.5G
>
>
> # ll /rhev/data-center/65c9777e-23f1-4f04-8cea-e7c8871dc88b/0a8035e6-e41d-40ff-a154-e0a374f264b2/images/75c54716-5222-4ad6-91f2-8b312eacc4b4/
> total 9995476
> -rw-rw----. 1 vdsm kvm     1048576 Nov 16 12:09
> 6ac73ee2-6419-43a4-91e7-7d4ef2026943_MERGE.lease
> -rw-rw----. 1 vdsm kvm 11811160064 Nov 16 13:32
> d4fa7785-8a89-4d13-9082-52556ab0b326
> -rw-rw----. 1 vdsm kvm     1048576 Mar 23  2013
> d4fa7785-8a89-4d13-9082-52556ab0b326.lease
> -rw-rw----. 1 vdsm kvm     1048576 Nov 16 13:29
> d4fa7785-8a89-4d13-9082-52556ab0b326_MERGE.lease
> -rw-r--r--. 1 vdsm kvm         274 Nov 16 13:29
> d4fa7785-8a89-4d13-9082-52556ab0b326.meta
>
> Thanks
> Gianluca
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users