2011/1/13 Daniel P. Berrange <berrange@xxxxxxxxxx>: > On Thu, Jan 13, 2011 at 01:06:00PM +0100, Matthias Bolte wrote: >> 2011/1/13 Daniel P. Berrange <berrange@xxxxxxxxxx>: >> > 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. >> >> Yes, we'll probably have to map between different lists of guest OS types. >> >> So we could go for the libosinfo list as source for a guest OS type >> element in the libvirt XML config and than map this onto the VMware >> list in the VMX generator and let virt-install maps its type/variant >> representation onto the libosinfo list. >> >> Another more VMware centric option would be to add an vmware namespace >> into the domain XML and just add the native VMware guest OS type >> there. > > I don't think we need togo that far. As far as libvirt/apps/hypervisors > are concerned the data format doesn't matter. Everyone just treats this > as an opaque string used as a key to lookup an entry a database of OS. > Thus all we need to know is what set the key belongs to. So we could > have an element that is > >  <os-id set='vmx|osinfo|...'>$FOO</os-id> > > In the libosinfo database we'd have > >     Âid=http://fedoraproject.org/fedora-10 >  Âshort-id=fedora10 >    Âname=Fedora 10 >   Âvmx-id=fedora-10 > > So, when creating a guest via the ESX / VMWare drivers > virt-manager would extract the 'vmx-id' field for the > entry the user selected in the UI, and pass that down > in the XML using  <os-id set='vmx'>fedora-10</os-id>. > The UI would of course have reduced the list of OS shown > to the user, to only include those with a 'vmx-id' field > actually present. > > While when using say QEMU, it would extract the 'short-id' > field for the user selection, and pass that down in the > XML using <os-id set='osinfo'>fedora10</os-id> > the database. > > This avoids the need for libvirt to talk directly to > libosinfo. The application can do that pass the info > down into libvirt, and also do the reverse lookup > when getting guest XML out of libvirt. > I like this approach. Quite simple but solves the problem and keeps all the mapping in one place. I think I'm going implement this in libvirt and also have a look at libosinfo. Matthias -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list