libvirt users - Oct 2015 - Re: Questions about qcow2 file size management

Hi all.

I have a few questions regarding the qcow2 format.

1/ Allocated size vs. file size

When creating a VM, I indicated a size of 10 G.

$ls -lsh

7,7G -rw------- 1 libvirt-qemu libvirt-qemu  11G oct.  14 10:04
prod.qcow2

The allocated size is lesser than max size. Alright.

I think I more or less grab the difference between allocated size and
file size, but I'm not sure I get the point of the auto-grow feature of
qcow2. 

Can someone confirm that if I have, say, a 60Go partition, I can create
more than six 10Go VM, as long as each don't actually use the full 10
Go? Sort of like flying companies selling more tickets than seats in the
plane assuming a few people won't come.

In other words, can I have this on a 60Go drive?
total 53G
7,4G -rw------- 1 root root 11G oct.   8 06:34 prod_151008.qcow2
7,4G -rw------- 1 root root 11G oct.   9 06:37 prod_151009.qcow2
7,5G -rw------- 1 root root 11G oct.  10 06:41 prod_151010.qcow2
7,5G -rw------- 2 root root 11G oct.  11 06:49 prod_151011.qcow2
7,5G -rw------- 1 root root 11G oct.  12 06:44 prod_151012.qcow2
7,5G -rw------- 1 root root 11G oct.  13 06:27 prod_151013.qcow2
7,7G -rw------- 1 root root 11G oct.  14 06:55 prod_151014.qcow2

(Total allocated is 53 < 60 but sum of 11G sizes is 77 G.)

If so, then I guess I get the point.

2/ Backup size

Is there a simple way to do backups that only take the actual allocated
space (7,7 G in my example) instead of the max (10 G)?

I'm using snapshots and blockcommits to backup a VM, thanks to help on
this list. The scripts are on GitHub for anyone interested [1].
Basically, what the script does is snapshot then cp as local backup
file. Then rsync to another backup partition. Both source and
destination partitions are ext4.

Source dir (where I cp the snapshots):

# ls -lsh vmbackup/daily/
total 53G
7,4G -rw------- 1 root root 11G oct.   8 06:34 prod_151008.qcow2
7,4G -rw------- 1 root root 11G oct.   9 06:37 prod_151009.qcow2
7,5G -rw------- 1 root root 11G oct.  10 06:41 prod_151010.qcow2
7,5G -rw------- 2 root root 11G oct.  11 06:49 prod_151011.qcow2
7,5G -rw------- 1 root root 11G oct.  12 06:44 prod_151012.qcow2
7,5G -rw------- 1 root root 11G oct.  13 06:27 prod_151013.qcow2
7,7G -rw------- 1 root root 11G oct.  14 06:55 prod_151014.qcow2

Destination (where rsync copies the files):

# ls -lsh /mnt/usb_hd/vm/vmbackup/daily/
total 71G
11G -rw------- 1 root root 11G oct.   8 06:34 prod_151008.qcow2
11G -rw------- 1 root root 11G oct.   9 06:37 prod_151009.qcow2
11G -rw------- 1 root root 11G oct.  10 06:41 prod_151010.qcow2
11G -rw------- 2 root root 11G oct.  11 06:49 prod_151011.qcow2
11G -rw------- 1 root root 11G oct.  12 06:44 prod_151012.qcow2
11G -rw------- 1 root root 11G oct.  13 06:27 prod_151013.qcow2
11G -rw------- 1 root root 11G oct.  14 06:55 prod_151014.qcow2

Allocated size is as big as file size. This kind of beats the point of
having qcow2 grow as needed.

Ideally, I would like to create VM with a huge max file size, but only
backup the actually used space. How may I achieve this?

I just tested 

qemu-img convert -O qcow2 prod_151008.qcow2 prod_151008_resize.qcow2

and I get 

7,2G -rw-r--r-- 1 root root 7,2G oct.  14 10:51 prod_151008_resize.qcow2

Seems to work. I could do this before rsyncing.

Is this the recommanded way? Is there a higher level libvirt command to
use instead of qemu-img?

3/ Playing with allocated space

My VM apparently has an allocated size of 7.7 G

7,7G -rw------- 1 libvirt-qemu libvirt-qemu  11G oct.  14 10:04
prod.qcow2

However, loging into it shows much less than 7.7 G is used:

$df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       9.8G  2.0G  7.3G  22% /
udev             10M     0   10M   0% /dev
tmpfs           2.0G   17M  2.0G   1% /run
tmpfs           4.9G  4.0K  4.9G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           4.9G     0  4.9G   0% /sys/fs/cgroup
tmpfs          1003M     0 1003M   0% /run/user/1000

I understand once qcow2 has grown to a given allocated size, it won't
de-allocate space automatically (auto-allocation is one way only).
Perhaps I ended up loading 7Go of files, then those were deleted and now
only 2Go are used but the file still has 7G allocated. Could be, but I
don't see when this might have happened. Could there be another
explanation?

Say I want to minimize allocated space because it is a pity to use 2 Go
and keep 7 Go backups (I know disk space is cheap, this is just an
example), how may I shrink allocated space to currently used space?

I'm not talking about shrinking the file, just minimizing the allocated
size to keep small backups as per former paragraph, still keeping max
file size big to let the VM grow further when needed.

In other words, I'm aiming at

2,7G -rw------- 1 libvirt-qemu libvirt-qemu  11G oct.  14 10:04
prod.qcow2

not at

2,7G -rw------- 1 libvirt-qemu libvirt-qemu  2,7G oct.  14 10:04
prod.qcow2

The guest is a Linux, BTW.

4/ Playing with qcow2 file sizes

Say I've got this file

7,7G -rw------- 1 libvirt-qemu libvirt-qemu  11G oct.  14 10:04
prod.qcow2

I'd like to make it bigger, like

7,7G -rw------- 1 libvirt-qemu libvirt-qemu  100G oct.  14 10:04
prod.qcow2

AFAIU, the steps would be  

- power off the VM

- expand the qcow2 file size

- from the host, extend the volume

- power on the VM

- from the guest, extend the filesystem

I've seen various post on the internet but I'm a bit confused and some
posts may be to old to consider new libvirt/qemu possibilities, so I'd
appreciate a safe pointer. (I'm also interested in reducing file size.)

Thanks for any hint.

[1] https://github.com/Jerome-github/vmbackup

-- 
Jérôme

Le 2015-10-14 11:34, Jérôme a écrit :
> 4/ Playing with qcow2 file sizes
I just found information about this on the wiki:

http://wiki.libvirt.org/page/Tips#Increasing_the_disk_size_of_a_virtual_machine

I'll post specific questions if I'm stuck.

Sorry for the noise.

-- 
Jérôme

On 2015-10-14 11:34, Jérôme wrote:
> In other words, can I have this on a 60Go drive?
> total 53G
> 7,4G -rw------- 1 root root 11G oct.   8 06:34 prod_151008.qcow2
> 7,4G -rw------- 1 root root 11G oct.   9 06:37 prod_151009.qcow2
> 7,5G -rw------- 1 root root 11G oct.  10 06:41 prod_151010.qcow2
> 7,5G -rw------- 2 root root 11G oct.  11 06:49 prod_151011.qcow2
> 7,5G -rw------- 1 root root 11G oct.  12 06:44 prod_151012.qcow2
> 7,5G -rw------- 1 root root 11G oct.  13 06:27 prod_151013.qcow2
> 7,7G -rw------- 1 root root 11G oct.  14 06:55 prod_151014.qcow2
> 
> (Total allocated is 53 < 60 but sum of 11G sizes is 77 G.)
> 
> If so, then I guess I get the point.
Yes. You just might need to figure out what to do if VMs suddenly start
to need more storage after all.
> 2/ Backup size
> 
> Is there a simple way to do backups that only take the actual allocated
> space (7,7 G in my example) instead of the max (10 G)?
I believe the mechanism you're searching for is sparse file handling.
Both rsync and cp can copy sparse files correctly; rsync does not do it
by default (--sparse), and cp's man page indicates that its automatic
sparse file detection is buggy (but manually specifying --sparse=always
should work).
> 3/ Playing with allocated space
> 
> My VM apparently has an allocated size of 7.7 G
> 
> 7,7G -rw------- 1 libvirt-qemu libvirt-qemu  11G oct.  14 10:04
> prod.qcow2
> 
> However, loging into it shows much less than 7.7 G is used:
TRIM is needed to indicate that space is reclaimable. This needs file
system support (no fat32, e.g.), and support by QEMU('s I/O driver).
Once Qemu is set up to accept TRIM, you can either enable the discard
mount option, or set up an fstrim cron job.



-- 
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwedas@tao.at | +43 (0)680 301 7167
http://software.tao.at

Le 2015-10-14 12:09, Sven Schwedas a écrit :
> On 2015-10-14 11:34, Jérôme wrote:
> 
>> In other words, can I have this on a 60Go drive?
>> total 53G
>> 7,4G -rw------- 1 root root 11G oct.   8 06:34 prod_151008.qcow2
>> 7,4G -rw------- 1 root root 11G oct.   9 06:37 prod_151009.qcow2
>> 7,5G -rw------- 1 root root 11G oct.  10 06:41 prod_151010.qcow2
>> 7,5G -rw------- 2 root root 11G oct.  11 06:49 prod_151011.qcow2
>> 7,5G -rw------- 1 root root 11G oct.  12 06:44 prod_151012.qcow2
>> 7,5G -rw------- 1 root root 11G oct.  13 06:27 prod_151013.qcow2
>> 7,7G -rw------- 1 root root 11G oct.  14 06:55 prod_151014.qcow2
>>
>> (Total allocated is 53 < 60 but sum of 11G sizes is 77 G.)
>>
>> If so, then I guess I get the point.
> 
> Yes. You just might need to figure out what to do if VMs suddenly start
> to need more storage after all.
Sure. I don't think I'll do this, but I wanted to be sure I understood
the mechanism correctly.

Thanks for the confirmation.
>> 2/ Backup size
>>
>> Is there a simple way to do backups that only take the actual allocated
>> space (7,7 G in my example) instead of the max (10 G)?
> 
> I believe the mechanism you're searching for is sparse file handling.
> Both rsync and cp can copy sparse files correctly; rsync does not do it
> by default (--sparse), and cp's man page indicates that its automatic
> sparse file detection is buggy (but manually specifying --sparse=always
> should work).
Exactly. I missed the "sparse" keyword for my research.

I modified the cp and rsync commands in my backup script and now I get
sparse files copied as sparse files, so my backup space won't get filled
with zeros.
 
>> 3/ Playing with allocated space
>>
>> My VM apparently has an allocated size of 7.7 G
>>
>> 7,7G -rw------- 1 libvirt-qemu libvirt-qemu  11G oct.  14 10:04
>> prod.qcow2
>>
>> However, loging into it shows much less than 7.7 G is used:
> 
> TRIM is needed to indicate that space is reclaimable. This needs file
> system support (no fat32, e.g.), and support by QEMU('s I/O driver).
> Once Qemu is set up to accept TRIM, you can either enable the discard
> mount option, or set up an fstrim cron job.
OK, I think I get the idea. I'll dig into this.

Thanks !

-- 
Jérôme