Re: [libvirt] VMware Workstation/Player support
2010/7/27 Daniel Veillard <veillard(a)redhat.com>:
On Tue, Jul 27, 2010 at 03:20:42PM +0200, Jean-Baptiste Rouault
wrote:
> Hi all,
>
> I'm working on the hynesim project (http://www.hynesim.org
> http://blog.hynesim.org).
> We are going to add VMware Workstation support to hynesim,
> so we would like to contribute to the development of a libvirt driver.
>
> There probably are multiple ways of doing this, one of them could
> be to use the VIX C API provided by VMware :
> http://www.vmware.com/support/developer/vix-api/
> However, the VIX license seems to be quite restrictive :
> http://www.vmware.com/download/eula/vixapi_eula.html
> I'm not a license expert so I don't know if this license forbids
> using the API in software like libvirt.
We had a look at the VIX Licence and it wasn't pretty, this EULA
seems to directly try to prevent reuse for anything except toying
with it.
We don't use VIX in the VPX/ESX/GSX driver for that reason either.
Also at the time the driver development started VIX had basic ESX
support since 3 weeks or so.
Another big problem is that it's not available for distribution
not packaged, it's a download from VMWare, i.e. it won't be present
in any build installation of distribution I think. As a result the
dependancy will make this impossible to support in default builds,
the only way being to download the vix library, and then rebuild
libvirt locally. Very painful !
I didn't realize this problem until now, but it's probably a bigger
problem than the license one.
> Another possibility could be to run VMware command line tools
> from libvirt to control guests.
That sounds quite a better option, first we avoid the licencing
tie in, second we can have the driver detect at runtime if the command
line tools are available, and then activate or not the driver. This
allows to provide the compiled support in all libvirt builds, even
if only a fraction of the users may actually use VMware Workstation.
So really it sounds like making the driver call directly the
command line tools is the right approach.
Code wise the driver should be installed in a directory separated
from src/esx , and some tweaking might be needed to 'export' the
ESX config parser and make it available from there, but that should
not be too hard really.
We'll need to move the VMX handling code from src/esx to src/util,
because drivers are not allowed to depend on each other.
That should be possible, but will require some refactoring, because
this code is currently closely entangled with the reset of the ESX
driver in some places and parts of it are probably quite ESX specific.
Matthias