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