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(a)tao.at | +43 (0)680 301 7167
http://software.tao.at
Attachments:
- signature.asc (application/pgp-signature — 648 bytes)