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

[Matthias Bolte]

2011/1/12 Eric Blake <eblake at redhat.com>:
> 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).

The subject of his mail says esx driver :)

Actually vmx is no hypervisor, but that directory contains the VMware
VMX config file handling code that is shared between the ESX and
VMware Player / Workstation driver.

> 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.
>
> 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.
>

Correct!

One thing I wonder about is, where to get the list of possible values
for the guest OS type and variation from? Do we use what
virt-install/virt-manager currently use and map that onto the fixed
guest OS types (and variations) that VMware and VirtualBox understand
in the ESX/VMware and VirtualBox driver? Or do we expose the list of
possible values in driver capabilities? Or ...

Matthias