Cloudmin kvm - raw/qcow2 disks

Hello, is it possible to create vm in cloudmin with kvm virtualization with qcow2 disk format ? If we create vm from template, it create raw disk with full preallocated disk space size. Also I tried to create template from existing qcow2 image, but cloudmin converted it to raw format although option "Whole disk (QCOW2)" was selected. Or maybe it possible do not preallocate all disk space with raw format? For example, it we have template with 2gb, and need to create vm with 50gb hdd, but don't want to allocate all disk space at once.

Also, second question: is it possible to use storage option "cache=none" by default with kvm virtualization in cloudmin?




No, qcow2 format is unlikely to be ever supported, for two reasons :

  1. There is no way to loopback mount the filesystem on a non-raw disk image, which prevents Cloudmin from accessing the filesystem when the VM is down or being created.

  2. The qcow2 format allows over-allocation of space, which could lead to filesystem corruption on the VM if the host system runs out of disk.

Regarding the cache=none storage option, this is set for swap disks already. Do you want it set for regular disks as well, so that only VM memory is used for caching?


Interacting with qcow2 is now possible via libguestfs/guestfish/virt-* tools.

Do these tools allow the filesystem to be mounted, or can they just read files from with a qcow2 image?


Have a look at, we use it at work to modify virtual machines images (not qcow though, but it should work the same) before releasing them to people, so instead of kpartx, mount, sed etc we just use virt-edit or guestfish. Especially have a look at virt-resize, as it is capable of cloning and expanding a partition/filesystem (even ntfs or lvm!), perfect for deploying templates. If you want to test it use the packages from here: Older ones have annoying bugs.

Wrt qcow2, be very careful at the performance issue when the image is not created with preallocation=metadata.

In all honesty, I wouldn't bother with it just yet, but it's good to keep an eye on these things..

PS: it should be possible to not preallocate all diskspace in raw img file, just create it with fallocate or smth.

Thanks, I'll take a look at it ..

I'm still leery of using qdow2 format, as it allows over-allocation which can be dangerous if the host system runs out of disk space.

That I personally agree with. Over-allocation is dangerous and confusing, if the customer insists on it maybe he will like OpenVZ better.

The main benefit of qcow2 imho is it allows snapshots, but this doesnt really work well (taking a snapshot pauses the VM for 30 minutes or more for me ... unacceptable downtime).. But it may get better in the near future.