[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 verizon net>
To: 	Doug Goldstein <cardoe 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 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
      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
 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.

 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


 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]