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 :|