On Thu, Jun 25, 2009 at 12:11:26PM +0200, Matthias Bolte wrote: > Hi, > > I'm still working on the VMX config to domain XML mapping for > dump/create XML, but it's not complete yet. I got distracted by other > urgent, Uni related work that had to be done first. Okay :-) > So I won't be able to complete the dump/create XML implementation > until tomorrow (freeze for the 0.6.5 release) that was requested in > order to get the driver merged into the official repository. But well, > with the short release cycle of libvirt not much is lost :) I expect we will have another release in approx 4 weeks, to be able to push features in Fedora 12, ESX support then would be great :-) > Some details on the VMX config to domain XML mapping: > > 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 yeah, I found their APIs increadibly confusing BTW... > heading for reading this information from the VMX config file, because > all needed information is concentrated in this file. Also, if one yes agreed thats probably way simpler in the end, and having a format conversion capability available at the virsh level will be useful in any case, so that code is needed anyway :-) > 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. that's good to know ! > 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. yes that sounds right > The next goal would be a basic create XML. I claimed before that I > would need to write an VMX config file to the ESX host in order to > create a new virtual machine, but as I dig trough the VI API in more > detail, it seems that this claim maybe false. I'll just have to test > this, but haven't had time to do it yet. on the other hand sending the VMX config may make the set of VI apis used simpler. > 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? Hum, that need to be though out a bit, as we do the same kind of things at the higher level (e.g. virt-install) and then convert that to various tweaks in the XML. I think Cole was starting to write a library to ease making per OS guest definitions, maybe we need to bring this down to libvirt level. I doubt the format at the XML level will be very hard, it's more a problem of making the information database available globally for the whole stack, either within libvirt or as a component that can be called consistently from top to bottom. > 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). Yes extending the Def and the XML (and RNG) syntax are things which are rather simple but we need to provide this in a consistant way, and that call to an API extension or a separate library. but we don't need this in a first step to build a first version of the ESX driver. thanks for the feedback, it's appreciated :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list