In looking at the processors, I'm noticing that there's a VmdkProcessor, but it seems to want ova format, not vmdk (it expects .ova extension, for example). Sort of confusing if we want to support both vmdk and ova.
On Sun, Dec 15, 2013 at 10:05 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > Actually, I'm wrong. It used to qemu-img convert qcow2 to qcow2, but > not any more. Qemu is actually just using vmdk natively. > > On Sun, Dec 15, 2013 at 9:33 PM, Marcus Sorensen <shadow...@gmail.com> wrote: >> I've been playing with this a little, and it seems that, interestingly >> enough, if I simply add 'vmdk' to the enum in >> api/src/com/cloud/storage/Storage.java, and tell CS about the file >> extension in server/src/com/cloud/template/HypervisorTemplateAdapter.java, >> KVM just seems to work with it. qemu-img autodetects the input format >> and converts it where it would normally would convert qcow2. This is >> partially enabled by the fact that we seem to qemu-img convert even >> qcow2 to qcow2 when copying templates to primary storage, so it just >> converted the vmdk as necessary. So as long as qemu-img has support >> for it, it seems you can upload any format and cloudstack will >> normalize to qcow2 (or raw, depending on primary storage format) when >> copying from secondary to primary. >> >> The preprocessor idea is interesting, but I do like the idea of >> eventually working toward having a single .qcow2 or .vmdk or .vhd that >> can be used by any hypervisor that's capable of converting it to >> native format upon copying to primary storage. >> >> On Sat, Dec 14, 2013 at 9:05 AM, Marcus Sorensen <shadow...@gmail.com> wrote: >>> 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. >>>> > >
