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