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

[Matthias Bolte]

2011/1/13 Daniel P. Berrange <berrange at redhat.com>:
> 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.
>

I like this approach. Quite simple but solves the problem and keeps
all the mapping in one place.

I think I'm going implement this in libvirt and also have a look at libosinfo.

Matthias