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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users