Size of vm created by qemu-img convert
 

I am using 'qemu-img convert' to convert a hyper-v vm into kvm. Problem is this creates the .img as the maximum virtual size (127Gb) rather than the actual machine size (24Gb) which is the size of the hyper-V file. Is there some way to set the file size during the convert?

Thanks,

Hi,

What's the exact command you've used?

Kind regards,

Eric

qemu-img convert –p –O raw ’/media/VM/Virtual hard disks/Win7Pro.vhd’ /vm/images/Win7Pro.img

Hi,

You could have used qcow2 which is a compressed format instead of raw and which can be perfectly used by kvm. The type 'raw' does no compression and uses all of the space originally assigned to the 'disk'. On the other hand if you use qcow2 for example the size will be significantly smaller. I have images which original disk size is set to 25 Gb and which in reality only occupy 2.5 Gb once installed. Have a look at the man page for qemu-img.

Kind regards,

Eric

no, but you can clean up the unused space after the conversion is done. qemu-img is able to deduplicate zero-blocks from an image, but first you need to fill the unused blocks in the VM by zeroes.

If this is a linux VM, simply use `dd if=/dev/zero of=/path/to/file` until it runs out of space, and delete that file. Then run `qemu-img convert ...` to get qemu-img to rerun over the image again, and remove the zero-filled chunks

EDIT: sfill is another linux option

for windows, look at sdelete, from sysinternals

Unfortunately Windows 7 VM not Linux.

read my previous post

Can I just confirm I have understood this completely; are you saying that if I run SDelete on the Win 7 VM first, then when I run 'qemu-img convert' that will automatically create a much smaller .img output file?

Is the qemu-ing convert -S option related to this issue in any way.

I seem to recall reading that RAW is the preferred format because it gives the fastest disk access, maybe I have got that wrong. Also a qcow2 vm cannot be resized downwards whereas a RAW vm can.

Don't know if it is going to work or not but I have decided to try:
1). Defrag each Win 7 VM internally
2). Shrink the NTFS file system within eash VM
3). qemu-image -resize to shrink the VM down to the size of the contained file system.

Next time the answer is obviously to reduce the max size of the VM forst in Hyper-V.

Hi,

It's only logical that RAW is the fastest since there's no compression/decompression involved when using the disk. On the other hand you were right about qcow2 not being able to 'downsize' the image only extend its size. I didn't know that but then again how many times would you need to downsize a qcow2 image? You could first downsize the raw format and then convert to a compressed file format like qcow2.

Kind regards,

Eric

1. I'm not aware of -S (maybe you meant -s?)
2. RAW provides the best disk speeds, because it has the least overhead, but it's also very low on features - it can't be a snapshot for example
3. What you mean to do is going to defeat the purpose of thin provisioning completely, and will not allow your VM to expand it's virtual disk automatically.

Well my intention is to reduce the VM it to a sensible size, say 40Gb, certainly not the 127Gb it has now ended-up as. It can always be expanded later if necessary by 'qemu-img resize' and then increasing the size of the VM's file system.

qemu-ing --help

That _a_ way to go, but it's not the best way IMO. If you zero out the unused blocks and then shrink the image using qemu-img, you will not have tp change the partition size, since the VM will keep believing it has the full size (and the image will be able to grow to the full size if need be)