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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list