Linux - Virtualization and CloudThis forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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.
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
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
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
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.
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.
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.
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.
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.
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
Quote:
-C indicated the consecutive number of bytes that must contain only zeros for qemu-img to create a sparse image during conversion
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.
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)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
