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: Intend to add OVA installation API > Date: Sun, 24 Jun 2012 22:45:15 -0400 > From: Bob Cochran <bcochran13@xxxxxxxxxxx> > To: Doug Goldstein <cardoe@xxxxxxxxxx> > > > > On 6/24/12 6:27 PM, Doug Goldstein wrote: > > On Sun, Jun 24, 2012 at 5:05 PM, Ata Bohra<ata.husain@xxxxxxxxxxx> 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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list