I thought the limitation was that qemu cannot take snapshots of vmdk On 12/16/13 3:04 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote:
>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. >>>>> > >
