[libvirt] VMware Workstation/Player support

[Matthias Bolte]

2010/7/27 Daniel Veillard <veillard at 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