Yeah. I don't think it would be so bad, since we already do qemu-img convert on any non-file based storage, or at least a copy. I think the impact would be negligible or none going from a vmdk template to raw compared to the existing qcow2 to raw, but definitely be felt on file based primary storage that normally just copies the template file. On Dec 14, 2013 4:35 AM, "Wido den Hollander" <w...@widodh.nl> wrote:
> > > 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. >>> >>> >>
