Likitha, This is not of value to VmWare only. We should make sure it works or has plugin points for all of the hypervisors. In general, how we support this today is through hypervisor capabilities to determine during orchestration and then on the Resource for each hypervisor, it can determine if it can support commands introduced for a functionality.
--Alex > -----Original Message----- > From: Likitha Shetty [mailto:likitha.she...@citrix.com] > Sent: Monday, September 30, 2013 10:30 AM > To: dev@cloudstack.apache.org > Subject: RE: [PROPOSAL] Support OVA files with multiple disks for templates > and uploaded volumes in VMWare > > True, OVA can contain any disk image type. I specifically called out VMware > because I was thinking about how today in CS this enhancement is of value > only to VMware. > > But yes, as you pointed out, during implementation we should ensure this > support is hypervisor agnostic. > > Thanks, > Likitha > > >-----Original Message----- > >From: Chip Childers [mailto:chipchild...@apache.org] > >Sent: Monday, September 30, 2013 10:06 PM > >To: dev@cloudstack.apache.org > >Subject: Re: [PROPOSAL] Support OVA files with multiple disks for > >templates and uploaded volumes in VMWare > > > >On Mon, Sep 30, 2013 at 03:26:54PM +0000, Likitha Shetty wrote: > >> Chip, > >> > >> In Cloudstack, for Xen and KVM hypervisors since the files used for > >> templates > >and volumes are virtual disks (VHD, QCOW2) the current CS assumption of > >template and volumes containing a single virtual disk seems fine. But > >since for VMware the files used for templates and volumes are in OVA > >format which is an archive that can contain multiple VMDKs this > >improvement seems appropriate only for VMware? > >> > >> Thanks, > >> Likitha > > > >Ok, I see why you are headed down a VMware only path now. That being > >said, OVF/OVA are actually envelope specs which can contain any disk > image type. > >The key is to either use the native HV OVF/A import capabilities > >(VMware obviously does this, as does XenServer IIRC), or use a tool > >like virt-tools to make the embedded meta-data about the included VM > useful for the target HV. > > > >While I get doing this for VMware only, I'd ask that the implementation > >be designed to potentially work with the other HVs. > > > >Make sense?
