[libvirt] Fwd: Re: Intend to add OVA installation API

[Daniel Veillard]

On Sun, Jun 24, 2012 at 10:47:01PM -0400, Bob Cochran wrote:
> Ooops, I should have sent this to the list. I want to support Doug's
> suggestion, thanks.
> 
> Bob Cochran
> 
> 
> -------- Original Message --------
> Subject: 	Re: [libvirt] Intend to add OVA installation API
> Date: 	Sun, 24 Jun 2012 22:45:15 -0400
> From: 	Bob Cochran <bcochran13 at verizon.net>
> To: 	Doug Goldstein <cardoe at cardoe.com>
> 
> 
> 
> On 6/24/12 6:27 PM, Doug Goldstein wrote:
> > On Sun, Jun 24, 2012 at 5:05 PM, Ata Bohra<ata.husain at hotmail.com>   wrote:
> >> Thanks Doug for your suggestions.
> >>
> >> I believe you are correct about the relation between OVA and OVF. But I am
> >> not 100 % possitive about your suggestion: "defining an appropriate domain
> >> in libvirt". To understand better I am sharing more details about my plans:
> >>
> >> 1. Enhance libvirt interface code (libvirt.c) to provide a
> >> domain-independent routine: virDomainCreateOVA, an alternate API to create
> >> domain.
> >>      To make client code real simple, this routine can take ova path as input
> >> and internally strip the OVA to extract required details. (planning to
> >> define a struct to hold all essential
> >>      information).
> >> 2. Second, to enhance ESX driver to perform ESX specfic calls.
> >>
> >> Given OVA is a tar file, the parsing is just another file open/read
> >> operation; it would be simple to perform it inside domain_conf.c (infact I
> >> have written a parser to strip information off OVA already).
> >>
> >> Hope to get some comments/suggestions on above steps.
> >>
> >> Thanks!
> >> Ata
> > Right. I'm suggesting you don't go that route and approach the problem
> > from another angle. I did a little Googling since my last e-mail to at
> > least make sure I understood the basics. So an OVF looks like the
> > following:
> >
> > virtualappliance/package.ovf
> > virtualappliance/disk1.vmdk
> > virtualappliance/disk2.vmdk
> > virtualappliance/cdrom.iso
> > virtualappliance/en-US-resources.xml
> >
> > An OVA would simply be a tar of the above and named

  Apparently that's what VMW defined somehow. I find a bit disturbing
that they used tar instead of some zip, as a ZIP can record indexes of
the parts and one doesn't have to scan the full tar to get the last
fragment for example.

> > virtualappliance.ova package.ovf is an XML file containing the
> > description of the hardware of the virtual machine, much like the XML
> > that libvirt stores about domains. While en-US-resources.xml would be
> > the US English descriptions of the machine and its hardware.

  I looked at some resources on OVF a long time ago when starting
libvirt and strugging with the XML content. There are of course some
commonalities, but the ovf is a bit of a higher level from my POV.

> > I'm suggesting you write an application that transforms package.ovf
> > into libvirt's own domain XML format and simply call
> > virDomainDefineXML() rather than adding API to libvirt itself. You
> > could then further extend the application to allow you to take a
> > libvirt domain and export it as a OVA.

  I'm sure one would have to pick some preferences as I think the OVF
data would be kind of a subset, but based on a given runtime environemnt
that should be easy. On a more general way it may be a bit hard.

> > Looking at VMWare and Xen, they both treat OVA/OVF as a foreign format
> > and require a converter application to import them to their native
> > internals so it wouldn't be much different than their approach.

  Yes the problem is that the data defined in the OVF is not 100%
sufficient to run the guest (or guests as you can have mutiple
instances in one OVF IIRC, but I assume it seldomly used !)

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/