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@xxxxxxxxxx From: cardoe@xxxxxxxxxx Subject: Re: Intend to add OVA installation API Date: Sun, 24 Jun 2012 15:31:43 -0500 To: ata.husain@xxxxxxxxxxx On Jun 24, 2012, at 2:30 PM, Ata Bohra <ata.husain@xxxxxxxxxxx> wrote:
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 |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list