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

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.