[libvirt] RFC: Enable Libvirt to handle OVA installation
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
On Wed, Dec 5, 2012 at 3:50 PM, Ata Bohra <ata.husain@hotmail.com> 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.
I thought this was discussed previously on the list before and the idea was to provide something similar to virt-v2v to convert from OVA into libvirt. Since effectively OVA machines are not really tied to any one virtualization solution but could be qemu or VMWare (or maybe VBox) VMs. It just the disk image and some high level definitions about the hardware. Or are you intending on this just being another storage driver for the VMWare driver? -- Doug Goldstein
Please see inline.> Date: Wed, 5 Dec 2012 17:24:00 -0600
Subject: Re: [libvirt] RFC: Enable Libvirt to handle OVA installation From: cardoe@gentoo.org To: ata.husain@hotmail.com CC: libvir-list@redhat.com
On Wed, Dec 5, 2012 at 3:50 PM, Ata Bohra <ata.husain@hotmail.com> 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.
I thought this was discussed previously on the list before and the idea was to provide something similar to virt-v2v to convert from OVA into libvirt. Since effectively OVA machines are not really tied to any one virtualization solution but could be qemu or VMWare (or maybe VBox) VMs. It just the disk image and some high level definitions about the hardware.
Or are you intending on this just being another storage driver for the VMWare driver? [AB] : Yes Doug, I remember you suggesting this idea earlier. I investigated this option trying to figure out how this can be done. It is not difficult to convert OVA description in to libvirt (with adding some exceptions etc) but then I hit the roadblock when it came to transfer of VM disk(s). OVA represents the disk in a compressed form and ESX hypervisor does not provide any API to upload compressed disk. Whereas, one of the steps in OVA installation is ESX providing you a lease object that allows uploading OVA compressed disk to the hypervisor that gets expanded internally. I'm not sure but I believe I reverted back with this observation. Do you think adding a driver object to handle OVA installation per specific hypervisor enviornment breaks the abstraction? I thought it would allow plugging right solution given the nature of hypervisor. > -- Doug Goldstein Thanks!Atahttp://abohra-libvirt.blogspot.com/
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 :|
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
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. [AB]: Unfortunately I could not find any way to perform this rather than accomodating it inside libvirt. As mentioned more of the issue is: OVA installation is handled by hypervisor in more than one step, they do not expose specific APIs to load compressed disk associated with one VM, please correct me if my understanding is wrong here. It means then this feature could be blessed within libvirt framework at all :(. For educational purpose, I want to ask why is "OVA installtion" is considered so alien. To me it is one of the ways to manage VM distribution in an hypervisor agnostic way. Thanks!Atahttp://abohra-libvirt.blogspot.com/
On Thu, Dec 6, 2012 at 5:41 PM, Ata Bohra <ata.husain@hotmail.com> wrote:
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.
[AB]: Unfortunately I could not find any way to perform this rather than accomodating it inside libvirt. As mentioned more of the issue is: OVA installation is handled by hypervisor in more than one step, they do not expose specific APIs to load compressed disk associated with one VM, please correct me if my understanding is wrong here. It means then this feature could be blessed within libvirt framework at all :(.
For educational purpose, I want to ask why is "OVA installtion" is considered so alien. To me it is one of the ways to manage VM distribution in an hypervisor agnostic way.
Point me to an OVA that's available and a way to load it & run it without forking money over to VMWare and I'll take a look and provide suggestions on how to best implement this for you. -- Doug Goldstein
participants (4)
-
Ata Bohra -
Daniel P. Berrange -
Doug Goldstein -
Jim Fehlig