Re: RFC: Enable Libvirt to handle OVA installation

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

 



On Wed, Dec 05, 2012 at 01:50:05PM -0800, Ata Bohra wrote:
> This is a proposal to enhance Libvirt library to handle OVA package installation.  OVA:
> OVA is one of the widely accepted and consortium defined/maintained format for 
> Virtual Machine distros. Technically it is a tar file with three main components:
> 1. VMX descriptor (XML file defining virtual machine specifics such as: virtual hardware etc.
> 2. VMDKs in a compressed format. 
> 3. Manifest file.  Proposal:
> 1. Expose a public API method to allow an application to invoke OVA installation with 
>    a file pointer to OVA file.  
> 2. OVA util file:
>    This file understands the OVA formats and rips out the given package to extract specific information:
>    2.1. int get_vmx(char *vmx): 
>         method can return VMX descriptor associated with a given OVA file. 
>    2.2. int get_vmdks(struct ova_type *ova):
>         method that seek the OVA file and populate ova_type struct which may look like;
>   typedef struct disk_list_tag {
>    char *file_name;
>    off_t file_size;
>    off_t file_offset;
>    struct disk_list_tag *next;
>   };
>   
>         typedef struct ova_type {
>    int num_vmdks;
>    ova_list *head;
>   }
> 2. Hypervisor specific changes:
>    It can be done in more than one way:
>    2.1: Enhance hypervisor driver function to implement hypervisor specific routines to
>         perform OVA installations. 
>    2.2.: Append a new driver to handle OVA installation such as virOvaDriver, main routines can be:
>          open() : parse OVA using util functions.
>    close()
>    list_disk(): may display disk names
>    install()   (Please suggest if there can be more routines to this driver, it can be enhanced later as well).
>   It is possible to design this driver to handle OVA parsing as well, but I think keeping it in
>   'util' may make that code available for all hypervisors given OVA format does not change per 
>   hypervisor.   I'm inclined more towards 2.2 design as it is more generic and provides room for furture extensions.  Looking forward for comments/suggestions.  Thanks!Ata 		 	   		  

I really don't want to see OVA support integrated into libvirt APIs.
libvirt aims to only provide the mechanism for virt management. OVA,
however, is a policy based approach to virt management. As such it
should be done by a layer above libvirt, which simply makes use of
the libvirt mechanism to accomplish its work. If there are specific
things that libvirt is missing, which prevent this layering, then
feel free to propose enhancements to the libvirt APIs to enable it.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
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]