Re: Intend to add OVA installation API

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

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]