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

Daniel P. Berrange berrange at redhat.com
Thu Jan 13 11:34:40 UTC 2011


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.


> 
> virt-manager has a gui drop-down box of potential guest os targets when
> creating a new domain description, but uses that primarily to optimize
> other choices (for example, should disks be ide or virtio) rather than
> something directly encoded in the XML.  Given that model, if
> virt-manager is used to create a vmx domain, then what does it matter if
> we set guestOS="other-64" and directly specify all other parameters to
> the same values that would have been the default that vmx would have
> used if the parameters were omitted, when compared to relying on
> guestOS='...' having a user-specified value?  That said, virt-manager
> would be another client that could populate a new XML element describing
> the guest os chosen at creation time.

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.


Daniel




More information about the libvir-list mailing list