> Date: Wed, 5 Dec 2012 17:24:00 -0600
> Subject: Re: [libvirt] RFC: Enable Libvirt to handle OVA installation
> From: cardoe@gentoo.org
> To: ata.husain@hotmail.com
> CC: libvir-list@redhat.com
>
> On Wed, Dec 5, 2012 at 3:50 PM, Ata Bohra <ata.husain@hotmail.com> wrote:
> > This is a proposal to enhance Libvirt library to handle OVA package
> > installation.
> >
> > OVA:
> > OVA is one of the widely accepted and consortium defined/maintained format
> > for
> > Virtual Machine distros. Technically it is a tar file with three main
> > components:
> > 1. VMX descriptor (XML file defining virtual machine specifics such as:
> > virtual hardware etc.
> > 2. VMDKs in a compressed format.
> > 3. Manifest file.
> >
>
> I thought this was discussed previously on the list before and the
> idea was to provide something similar to virt-v2v to convert from OVA
> into libvirt. Since effectively OVA machines are not really tied to
> any one virtualization solution but could be qemu or VMWare (or maybe
> VBox) VMs. It just the disk image and some high level definitions
> about the hardware.
>
> Or are you intending on this just being another storage driver for the
> VMWare driver?
[AB] : Yes Doug, I remember you suggesting this idea earlier. I investigated this option trying to figure out how this can be done. It is not difficult to convert OVA description in to libvirt (with adding some exceptions etc) but then I hit the roadblock when it came to transfer of VM disk(s). OVA represents the disk in a compressed form and ESX hypervisor does not provide any API to upload compressed disk. Whereas, one of the steps in OVA installation is ESX providing you a lease object that allows uploading OVA compressed disk to the hypervisor that gets expanded internally. I'm not sure but I believe I reverted back with this observation.
Do you think adding a driver object to handle OVA installation per specific hypervisor enviornment breaks the abstraction? I thought it would allow plugging right solution given the nature of hypervisor.