[libvirt] VMware ESX driver status update

[Daniel P. Berrange]

On Thu, Jun 25, 2009 at 12:11:26PM +0200, Matthias Bolte wrote:
> I claimed before that I would need to read most information needed for
> dump XML from the VMX config file. That's not true. Possibly all
> information can be retrieved via VI API, but the information is
> scattered in various places in the VI API object model. I'm currently
> heading for reading this information from the VMX config file, because
> all needed information is concentrated in this file. Also, if one
> changes properties of a virtual machine via VI API and this properties
> is reflected in the VMX config, the ESX host updates the VMX config,
> so the information is kept in sync between the object model and the
> config file.
> 
> I guess, that the VMX config files contains enough information to fill
> all or at least most fields of a virDomainDef. So the first goal is to
> fill a virDomainDef for dump XML.

The thought occurs to me, that using VMX config files would also
enable someone to write a libvirt driver for VMWare Desktop too,
since that uses VMX format files. 

> One problem here is the essential guestOS field of the VMX config, see
> http://sanbarrow.com/vmx/vmx-guestos.html . For a first try I would
> set it to 'other' by default, because there is currently no field
> available in the domain XML to map this information to. But to allow
> the user to set this filed, I would want to extend to domain XML
> definition in order to reuse existing code. So how would I do this?
> Currently I'm just using the virDomainDef struct and the related parse
> and format functions. One option would be to add a guest field to the
> virDomainOSDef struct and extend the parse and format functions to
> handle it. The parse and format functions take flags already, so a
> flag could be added to indicate if the guest field should be handled
> or not (just like the VMX extension for the virConfParser).

We don't generally use flags in the parser method for turning on/off
hypervisor specific pieces. Our goal for the XML is to figure a format
that is usable for all hypervisors, even if only one currently 
implements it. So we'd want to try and figure our how to present this
OS type information.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|