[libvirt] Intend to add OVA installation API
Hi Everyone, I am relatively new to libvirt community; have worked on it from last half year mostly towards adding few missing APIs especially for ESX driver. One of the features I worked was installing a domain (VM) using OVAs. It is been a long time OVA became defacto standard for distributing and installing Virtual Machines, but surprisingly libvirt does not provide support for it. I wanted to perform a quick sanity int the community so that I am not stepping on anyone feet here. So far, I have working code, but to contribute upstream would require a bit of a cleanup work. One of the concern that I intend to get inputs on: OVA is a tar format archive, the first pre-requisite is to parse OVA and get following information: 1. XML descriptor. 2. VMDKs for transfer after domain is created on the hypervisor. (in ESX world that is done by getting a lease object and then transmitting the disk bits to hypervisor) I am wondering, where should I put the common code to parse OVA? My initial thought is to enhance conf/domain_conf.* file, given it already provides parsing routines for XML descriptor. Waiting for your feedback on this one. As I am familiar with ESX libvirt interaction, so the immediate plan is to enhance ESX driver, hopefully in near future will contribute the same feature to KVM/Xen etc. Thanks! Ata
On Jun 24, 2012, at 2:30 PM, Ata Bohra <ata.husain@hotmail.com> wrote:
Hi Everyone,
I am relatively new to libvirt community; have worked on it from last half year mostly towards adding few missing APIs especially for ESX driver. One of the features I worked was installing a domain (VM) using OVAs. It is been a long time OVA became defacto standard for distributing and installing Virtual Machines, but surprisingly libvirt does not provide support for it. I wanted to perform a quick sanity int the community so that I am not stepping on anyone feet here. So far, I have working code, but to contribute upstream would require a bit of a cleanup work.
One of the concern that I intend to get inputs on:
OVA is a tar format archive, the first pre-requisite is to parse OVA and get following information: 1. XML descriptor. 2. VMDKs for transfer after domain is created on the hypervisor. (in ESX world that is done by getting a lease object and then transmitting the disk bits to hypervisor)
I am wondering, where should I put the common code to parse OVA? My initial thought is to enhance conf/domain_conf.* file, given it already provides parsing routines for XML descriptor. Waiting for your feedback on this one.
As I am familiar with ESX libvirt interaction, so the immediate plan is to enhance ESX driver, hopefully in near future will contribute the same feature to KVM/Xen etc.
Thanks! Ata
Going off of pure memory here but I believe OVA and OVF are related somehow (one is a sub or super set or one can have multiple machines) but there is already some lifting being done by open-ovf. One of our guys at work used it to convert some VMWare OVA/OVF VMs to qemu VMs and got them into libvirt. I know there were some really rough edges but it's worth looking at their code as an option. Basically this would involve not teaching libvirt to read OVA format but unpacking that format and defining an appropriate domain in libvirt. Similiar to what virtinst does now. The added flexibility is that you could migrate from VMWare to qemu or Xen at the same time. I'll try to dig up some scripts on Monday. -- Doug
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 CC: libvir-list@redhat.com From: cardoe@cardoe.com Subject: Re: [libvirt] Intend to add OVA installation API Date: Sun, 24 Jun 2012 15:31:43 -0500 To: ata.husain@hotmail.com On Jun 24, 2012, at 2:30 PM, Ata Bohra <ata.husain@hotmail.com> wrote: Hi Everyone, I am relatively new to libvirt community; have worked on it from last half year mostly towards adding few missing APIs especially for ESX driver. One of the features I worked was installing a domain (VM) using OVAs. It is been a long time OVA became defacto standard for distributing and installing Virtual Machines, but surprisingly libvirt does not provide support for it. I wanted to perform a quick sanity int the community so that I am not stepping on anyone feet here. So far, I have working code, but to contribute upstream would require a bit of a cleanup work. One of the concern that I intend to get inputs on: OVA is a tar format archive, the first pre-requisite is to parse OVA and get following information: 1. XML descriptor. 2. VMDKs for transfer after domain is created on the hypervisor. (in ESX world that is done by getting a lease object and then transmitting the disk bits to hypervisor) I am wondering, where should I put the common code to parse OVA? My initial thought is to enhance conf/domain_conf.* file, given it already provides parsing routines for XML descriptor. Waiting for your feedback on this one. As I am familiar with ESX libvirt interaction, so the immediate plan is to enhance ESX driver, hopefully in near future will contribute the same feature to KVM/Xen etc. Thanks! Ata Going off of pure memory here but I believe OVA and OVF are related somehow (one is a sub or super set or one can have multiple machines) but there is already some lifting being done by open-ovf. One of our guys at work used it to convert some VMWare OVA/OVF VMs to qemu VMs and got them into libvirt. I know there were some really rough edges but it's worth looking at their code as an option. Basically this would involve not teaching libvirt to read OVA format but unpacking that format and defining an appropriate domain in libvirt. Similiar to what virtinst does now. The added flexibility is that you could migrate from VMWare to qemu or Xen at the same time. I'll try to dig up some scripts on Monday. --Doug
On Sun, Jun 24, 2012 at 5:05 PM, Ata Bohra <ata.husain@hotmail.com> 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
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: [libvirt] Intend to add OVA installation API From: cardoe@cardoe.com To: ata.husain@hotmail.com CC: libvir-list@redhat.com
On Sun, Jun 24, 2012 at 5:05 PM, Ata Bohra <ata.husain@hotmail.com> 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
Ata Bohra <ata.husain <at> hotmail.com> writes:
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: [libvirt] Intend to add OVA installation API> From: cardoe <at> cardoe.com> To: ata.husain <at> hotmail.com> CC: libvir-list <at> redhat.com> > On Sun, Jun 24, 2012 at 5:05 PM, Ata Bohra <ata.husain <at> hotmail.com> 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
Hi Ata Bohra, I am very happy to see this mail chain on OVF to libvirt xml conversion. I appreciate your efforts on this. Even we are looking to have this kind of conversion utility. Could you please share if you have more details on this? Thanks in advance. Best Regards Raghu
-----Original Message----- From: Raghunatha Reddy Sent: Tuesday, July 10, 2012 1:53 AM To: libvir-list@redhat.com Subject: Re: [libvirt] Intend to add OVA installation API Ata Bohra <ata.husain <at> hotmail.com> writes:
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: [libvirt] Intend to add OVA installation API> From: cardoe <at> cardoe.com> To: ata.husain <at> hotmail.com> CC: libvir-list <at> redhat.com> > On Sun, Jun 24, 2012 at 5:05 PM, Ata Bohra <ata.husain <at> hotmail.com> 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
Hi Ata Bohra, I am very happy to see this mail chain on OVF to libvirt xml conversion. I appreciate your efforts on this. Even we are looking to have this kind of conversion utility. Could you please share if you have more details on this? Thanks in advance. Best Regards Raghu Hi Raghu, As mentioned in the mail above, I am currently stuck at "transferring disk to ESX". OVAs store the vmdks in "stream optimized" fashion and sweeping over vSphere documentation I could not find any API to uncompress the disk after transferring it to ESX. Recently Matthias appended libvirt with the support to upload volumes but for installing OVA I am not sure that will be useful. Lastly, I posted request to allow addition of public API to install OVA to libvirt layer; response is still awaited. If that's permissible, rolling out the code to install OVA on ESX should not take long. Hope, I was able to reply to your query. Thanks! Ata -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (4)
-
Ata Bohra -
Ata E Husain Bohra
-
Doug Goldstein -
Raghunatha Reddy