|
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@xxxxxxxxxx > To: ata.husain@xxxxxxxxxxx > CC: libvir-list@xxxxxxxxxx > > 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 > 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 |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list