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

[Bob Cochran]

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
>  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'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.
>
>  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.
>
>  Just my 2 cents.

I really like what Doug suggests here.

Bob Cochran