qcow2 format Support.

This is expected - the qcow2 format is not supported by Cloudmin, as the disk images cannot be directly accessed and mounted on the host system.

Jamie,

Have you looked at libguestfs? I think using it might resolve this problem. http://libguestfs.org/ http://libguestfs.org/guestfs-perl.3.html

" libguestfs is a set of tools for accessing and modifying virtual machine (VM) disk images. You can use this for viewing and editing files inside guests, scripting changes to VMs, monitoring disk used/free statistics, creating guests, P2V, V2V, performing backups, cloning VMs, building VMs, formatting disks, resizing disks, and much more.

libguestfs can access almost any disk image imaginable. It can do it securely — without needing root and with multiple layers of defence against rogue disk images. It can access disk images on remote machines or on CDs/USB sticks. It can access proprietary systems like VMware and Hyper-V. "

No, we haven't looked into that - Cloudmin uses loopback mounting instead to access files inside the VM disk using regular Linux tools.

I still wouldn't recommend qcow2 for a production system, as the way it overcommits disk space could cause VMs to corrupt their filesystems if the host runs out of disk.

Yeah, running out of disk space is a worry and extra logic would need to be added to protect against that.

I don't think it's even possible - because the qcow2 file grows as new blocks are used on the VM disk, if the host filesystem is full then writing a file inside the VM can fail - and it will look to the VM kernel like a disk error.

Yes, I agree it gets tricky. Using raw files as it is now is much simpler.

If you were to switch to qcow2, then you'd have to calculate for space requirements on the hypervisor using qemu-img output (or via perl bindings if any); for example using the "virtual size" as per the below.

Like this you know which is the maximum size that file can reach - unless you are using snapshots which will add to the size.

At the same time though, qcow2 allows for much nicer deployments from templates, thus saving quite a bit of space and the backups will also be less massive and take less time, overall easier on I/O.

Right, I can see the attraction of qcow2 - I just don't consider it safely usable in a production environment.

Also, when using LVM for VM disks, there is less space-saving benefit because the LV needs to be sized in advance to the maximum disk size.

Jamie,

Cloudstack, Openstack, OpenNebula, oVirt all use it; hardly an expert, but never had problems with it.

Cloudstack and Openstack use a "golden image" approach to deploy VMs, where a new instance is spawned as a writable snapshot of it. It's a very, very fast operation and saves disk space. Similarly backups are also quite fast.

Said cloud systems use a different approach to VMs, ie a single partition (or /boot and /) and the use of cloud-init which is capable to retrieve metadata such as passwords, IPs etc and set them inside the guest.

Cloud-init will also resize the partition to match the target disk, so no need to perform any operation on the guest.

A much cleaner approach all in all. Personally I'd be thrilled to see Cloudmin using a similar approach.

Happy to help if there's interest.

I'm sure that most of the time, these kinds of formats are fine - however, any kind of disk space over-commitment is inherently risky and I'd be very nervous using it with production VMs.

So Cloudmin won't be supporting qcow2 formats at all?

No, I don't think we can ever support that format.