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
Jérôme
2015-Oct-14 09:55 UTC
Re: [libvirt-users] Questions about qcow2 file size management
Le 2015-10-14 11:34, Jérôme a écrit :> 4/ Playing with qcow2 file sizesI 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
Sven Schwedas
2015-Oct-14 10:09 UTC
Re: [libvirt-users] Questions about qcow2 file size management
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
Jérôme
2015-Oct-14 11:27 UTC
Re: [libvirt-users] Questions about qcow2 file size management
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