other: 0.097 device: 0.096 permissions: 0.092 semantic: 0.077 PID: 0.076 performance: 0.075 debug: 0.073 vnc: 0.071 socket: 0.070 files: 0.066 graphic: 0.054 KVM: 0.053 boot: 0.051 network: 0.049 debug: 0.573 files: 0.118 other: 0.096 device: 0.034 PID: 0.032 KVM: 0.025 semantic: 0.020 vnc: 0.017 boot: 0.017 socket: 0.017 performance: 0.017 network: 0.016 graphic: 0.013 permissions: 0.007 "qemu-img convert -O qcow2 -o backing_file" makes huge images $ dd if=/dev/urandom bs=1M of=1.img count=4 4+0 records in 4+0 records out 4194304 bytes (4,2 MB) copied, 1,0413 s, 4,0 MB/s $ qemu-img create -f qcow2 -b 1.img 2.img Formatting '2.img', fmt=qcow2 size=4194304 backing_file='1.img' encryption=off cluster_size=0 $ qemu-img convert -O qcow2 -o backing_file=1.img 2.img 3.img $ du -h ?.img 4,1M 1.img 144K 2.img 4,3M 3.img The conversion result is bigger then the source! It appears that "-o backing_file" is not applied to data (as expected). I.e. all data is put into the resulting image: both from source image and "backing" image. Expected behavior is to put only data that is not present in backing_file. It is possible to chain backing files. As a workaround you could do the following: $ qemu-img create -f qcow2 -b 2.img 4.img # from now on don't modify 2.img, instead use 4.img $ qemu-img create -f qcow2 -b 2.img 3.img # here is the 3.img you tried to create with qemu-convert Images 1.img and 2.img should never be modified, they are immutable snapshots. Images 3.img and 4.img can be modified and will contain only changes against 2.img. Perhaps qemu-img needs a command to drop data that is duplicated in the base image. This could be a new flag to commit: qemu-img commit --dedup 3.img. Do you confirm this as a bug? Sorry I'm not a frequent Launchpad user and will leave it up to someone more familiar to decide which status to place it in. On Thu, Oct 14, 2010 at 1:26 PM, Anthony Liguori