This question was asked on IRC:
$ virt-builder centos-6 --output box.img --format qcow2 --size 40G # ...
$ qemu-img convert -O qcow2 box.img box-qcow2.img
$ ls -lAhs
1.6G -rw-r--r--. 1 james 41G Jan 2 21:53 box.img
1.1G -rw-r--r--. 1 james 1.1G Jan 3 18:54 box-qcow2.img
$ file box*
box.img: QEMU QCOW Image (v2), 42949672960 bytes
box-qcow2.img: QEMU QCOW Image (v2), 42949672960 bytes
I can reproduce this as well. It turns out to be because virt-builder
runs the following command to create the output container:
qemu-img create -f qcow2 -o preallocation=metadata box.img 42949672960
which you can see produces an apparently huge, but *sparse* file:
$ ls -lh box.img
-rw-r--r--. 1 rjones rjones 41G Jan 4 12:56 box.img
$ du -sh box.img
6.4M box.img
Note that the output file from virt-builder is also sparse:
$ ls -lh box.img
-rw-r--r--. 1 rjones rjones 41G Jan 4 12:55 box.img
$ du -sh box.img
935M box.img
so I don't think this counts as a bug, but I'm surprised that qemu-img
+ -o preallocation=metadata causes such an (apparently) huge file to
be created. It's not taking up as much disk space as it appears to.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW