[libvirt] esx driver: XML format for guest OS type/variant

[Daniel P. Berrange]

On Thu, Jan 13, 2011 at 01:06:00PM +0100, Matthias Bolte wrote:
> 2011/1/13 Daniel P. Berrange <berrange at redhat.com>:
> > On Wed, Jan 12, 2011 at 03:16:00PM -0700, Eric Blake wrote:
> >> On 01/10/2011 06:53 PM, Jake Xu wrote:
> >> > Hi,
> >> >
> >> > I am trying to create a VM using the Python bindings of Libvirt. I can
> >> > successfully create VM from a XML template, but I can't find any way to
> >> > define the guest OS type/variant like CentOS 5.5 64bit for my VM. The native
> >> > format converted from XML is always guestOS="other-64" - which doesn't tell
> >> > us much about the guest operating system.
> >>
> >> Which hypervisor are you using (aka which URI are you using when
> >> creating your connection to libvirt), and how important is the guestOS=
> >> parameter to that hypervisor?  I'm guessing you are targetting vmx (as
> >> that was the only place in libvirt source code where guestOS appeared).
> >>
> >> It may be worth adding an optional XML element that records a string to
> >> use for the guestOS argument.  In fact, the libguestfs tool suite
> >> already has some pretty decent ways to guess the OS of an arbitrary VM
> >> guest (even when using other hypervisors, like qemu-kvm, which don't
> >> have any counterpart of a guestOS argument in native format), but it
> >> takes several seconds to figure that out per domain.  libguestfs would
> >> certainly be pleased with a way to annotate guestOS details into an XML
> >> description, rather than having to relearn it every time.
> >
> > The hard part is deciding what values we put in the XML. The way
> > we did this for virt-manager/virt-install, of picking a 'variant'
> > and 'type' is rather flawed split in retrospect so I don't want
> > to save those values in the XML.
> >
> > In the libosinfo project we have gone for a different approach
> > where we have a unique URI that identifies every single OS
> > release, and we use the vendor's own official name as the
> > human friendly string. We also provide a short key for the
> > OS.
> >
> > eg,
> >
> >        id=http://fedoraproject.org/fedora-10
> >  short-id=fedora10
> >      name=Fedora 10
> >
> > The further complication is that VMWare won't care about any
> > of these names, nor the current virt-install/virt-manager
> > names. It has its own naming scheme we'll need to write in
> > the VMX file.
> 
> Yes, we'll probably have to map between different lists of guest OS types.
> 
> So we could go for the libosinfo list as source for a guest OS type
> element in the libvirt XML config and than map this onto the VMware
> list in the VMX generator and let virt-install maps its type/variant
> representation onto the libosinfo list.
> 
> Another more VMware centric option would be to add an vmware namespace
> into the domain XML and just add the native VMware guest OS type
> there.

I don't think we need togo that far. As far as libvirt/apps/hypervisors
are concerned the data format doesn't matter. Everyone just treats this
as an opaque string used as a key to lookup an entry a database of OS.
Thus all we need to know is what set the key belongs to. So we could
have an element that is 

   <os-id set='vmx|osinfo|...'>$FOO</os-id>

In the libosinfo database we'd have

          id=http://fedoraproject.org/fedora-10
    short-id=fedora10
        name=Fedora 10
      vmx-id=fedora-10

So, when creating a guest via the ESX / VMWare drivers
virt-manager would extract the 'vmx-id' field for the
entry the user selected in the UI, and pass that down
in the XML using   <os-id set='vmx'>fedora-10</os-id>.
The UI would of course have reduced the list of OS shown
to the user, to only include those with a 'vmx-id' field
actually present.

While when using say QEMU, it would extract the 'short-id'
field for the user selection, and pass that down in the
XML using <os-id set='osinfo'>fedora10</os-id>
the database.

This avoids the need for libvirt to talk directly to
libosinfo. The application can do that pass the info
down into libvirt, and also do the reverse lookup
when getting guest XML out of libvirt.

> >
> > The existance of 'other-64' is another flaw in the way we approached
> > this in virt-manager. It is a hack to get around fact that the data
> > is not extendable by the admins. In libosinfo we went for something
> > that is user extendable in plain text data files.
> 
> Actually other-64 is on of the VMware guest OS types. The VMX code
> uses "other" or "other-64" based on the given architecture of the
> guest, because the guestOS entry is mandatory.

Ah, well virt-install has a similar generic option.

Daniel