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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list