2011/1/12 Eric Blake <eblake(a)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