Sure, I'll take a look, it might just do the trick. I imagine this would be run in the SSVM? On the other hand, if we pass off format conversation to the hypervisors template copy as discussed, we could move toward multi hypervisor templates, where you can upload and store a single vmdk or vdi and the hypervisors just convert as necessary when copying to primary storage. On Dec 14, 2013 8:04 AM, "Alex Huang" <alex.hu...@citrix.com> wrote:
> Marcus, > > When I refactored the template upload process ages ago, I left in an > interface called Processor.java. The whole purpose of which was to allow > others to add post processing of the template once its been uploaded. Such > conversions can be done there. Take a look and see if it suits your > purposes. > > --Alex > > > -----Original Message----- > > From: Marcus Sorensen [mailto:shadow...@gmail.com] > > Sent: Saturday, December 14, 2013 12:06 AM > > To: dev@cloudstack.apache.org > > Subject: Re: kvm - why just qcow2 > > > > 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. > > 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. > > > >
