2011/1/12 Eric Blake <eblake@xxxxxxxxxx>: > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list