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