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. >>> > >
