On 12/14/2013 09:05 AM, Marcus Sorensen wrote:
I suppose it would be best, and probably easiest, to accept templates in
vmdk, vdi, etc, but qemu-img convert to qcow2 during the copy to primary
storage, to keep the agent code from dealing with many formats. There's a
lot of code that would need rework to deal with non-qcow2 file based disks.
I ran into this when implementing RBD. Since the code made all kinds of
assumptions when it came to the format. RBD uses RAW (how KVM sees it).
That's why I wrote QemuImg.java to abstract most of that work.
But I agree with you, we shouldn't force ourselfs into QCOW2, but we
should be aware that the hypervisors could be doing a lot of converting
work.
Wido
On Dec 13, 2013 10:39 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote:
Is there any reason why we only support qcow2 format on KVM? It seems
like it would be fairly simple to support other formats, qemu-img can
handle going from VMDK to RAW for example, and qemu-kvm can even use
VMDK, QED, and other formats. It even seems like QemuImg.java was
written with other formats in mind. It seems like it wouldn't be a lot
of work to simply let other formats come through, we might have to
change LibvirtVMDef a bit so it can make the proper XML.
