|
(resending the same draft, nasty OVA somehow made to the start of the email text :-) )
Hi Doug, Daneil et. al. I am experimenting with the idea suggested by Doug from last couple of day, though the information provided by OVF may not be 100% but still it contains sufficient information to create a domain. I agree libvirt domain XML provides more advanced configuration options, but OVF portability and standard can provide instant provisioning of VMs. It was not difficult to map OVF tags to corresponding libvirt domain XML fields; but I am stuck at how to transfer disk to ESX hyerpvisor (as I am working on ESX so trying with it at first). I added an API call to ESXStorageDriver to upload volume (posted the patch in a different post), but VMDK inside OVF/OVA needs processing which is normally done by ESX exposed APIs. Please provide suggestions w.r.t issue (these APIs are part of vAppInstall, their is no isolated API to just upload OVF/OVA disk to the hypervisor). If there is no way to resolve this disk formatting/upload issue, then, will it be a good idea to expose livbirt level interface to install OVA/OVF so that each hypervisor can implement the supported APIs to install OVA/OVF? Thanks all for your suggestions/comments. Thanks! Ata From: ata.husain@xxxxxxxxxxx To: veillard@xxxxxxxxxx; bcochran13@xxxxxxxxxxx; cardoe@xxxxxxxxxx Date: Sun, 1 Jul 2012 03:34:11 +0530 CC: libvirt-list@xxxxxxxxxx Subject: Re: [libvirt] Fwd: Re: Intend to add OVA installation API OVAHi Doug, Daneil et. al.
I am experimenting with the idea suggested by Doug from last couple of day, though the information provided by OVF may not be 100% but still it contains sufficient information to create a domain. I agree libvirt domain XML provides more advanced configuration options, but OVF portability and standard can provide instant provisioning of VMs. It was not difficult to map OVF tags to corresponding libvirt domain XML fields; but I am stuck at how to transfer disk to ESX hyerpvisor (as I am working on ESX so trying with it at first). I added an API call to ESXStorageDriver to upload volume (posted the patch in a different post), but VMDK inside OVF/OVA needs processing which is normally done by ESX exposed APIs. Please provide suggestions w.r.t issue (these APIs are part of vAppInstall, their is no isolated API to just upload OVF/OVA disk to the hypervisor). If there is no way to resolve this disk formatting/upload issue, then, will it be a good idea to expose livbirt level interface to install OVA/OVF so that each hypervisor can implement the supported APIs to install OVA/OVF? Thanks all for your suggestions/comments. Thanks! Ata > Date: Mon, 25 Jun 2012 15:05:40 +0800 > From: veillard@xxxxxxxxxx > To: bcochran13@xxxxxxxxxxx > CC: libvirt-list@xxxxxxxxxx > Subject: Re: [libvirt] Fwd: Re: Intend to add OVA installation API > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list