[libvirt] VMware ESX driver status update

Hugh O. Brock hbrock at redhat.com
Thu Jun 25 15:33:22 UTC 2009


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




More information about the libvir-list mailing list