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

Re: [libvirt] RFC: Enable Libvirt to handle OVA installation



Daniel P. Berrange wrote:
> 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.

Agreed.  The open-ovf project was an attempt at such a layer, but AFAIK
it is a dead project.  As I recall, the code was rather complex for the
task, and is likely lagging the current OVF specs, but it might be
useful for reference

https://gitorious.org/open-ovf

Regards,
Jim


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