3:46 p.m.
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?
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
11:56 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4023
days inactive
4024
days old
1 comments
2 participants
participants (2)
-
Bob Doolittle -
Gianluca Cecchi