On Thu, Jun 25, 2009 at 05:26:45PM +0200, Daniel Veillard wrote: > On Thu, Jun 25, 2009 at 12:11:26PM +0200, Matthias Bolte wrote: > > > 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. > Yes, Cole got a start on the library, got some feedback from various folks, but I don't know what the current status is. We also need this for oVirt and for various other interesting libguestfs interactions (virt-inspector...). If you think it's in scope for libvirt I would love to have it there, it would make things easier for us. --Hugh -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list