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.