Ata Bohra <ata.husain <at> hotmail.com> writes: > > > Thanks again Doug. With this direction, I have started looking into details of both formats and also to convert OVF -> libvirt domain XML format. Will post the review once I get a satisfactory code to share with the community. Appreciate your support/suggestion. Thanks!Ata > Date: Sun, 24 Jun 2012 17:27:03 -0500> Subject: Re: Intend to add OVA installation API> From: cardoe <at> cardoe.com> To: ata.husain <at> hotmail.com> CC: libvir-list <at> redhat.com> > 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.> -- > Doug Goldstein > Hi Ata Bohra, I am very happy to see this mail chain on OVF to libvirt xml conversion. I appreciate your efforts on this. Even we are looking to have this kind of conversion utility. Could you please share if you have more details on this? Thanks in advance. Best Regards Raghu -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list