[libvirt] esx driver: XML format for guest OS type/variant
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. I have looked at the C libvirt source code a bit, and it seems like libvirt does not support defining guest os type using XML description yet. Is there any way I can set the guest OS type for my VM? Thanks, Jake
On 11/01/2011, at 12: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.
I have looked at the C libvirt source code a bit, and it seems like libvirt does not support defining guest os type using XML description yet.
Ouch, that sounds less than optimal.
Is there any way I can set the guest OS type for my VM?
I'm not a Python programmer, but wondering if you'd be able to cheat by looking how virt-manager does it? http://virt-manager.org/scmrepo.html Virt-manager uses Mercurial for source control, which unfortunately I don't know how to work with either, so can't point you directly to the right file to check. But, if you want to look, you should be able to check out the repository (however Mercurial does it) and then find the right code pretty fast. Is that helpful? Regards and best wishes, Justin Clift
2011/1/12 Justin Clift <jclift@redhat.com>:
On 11/01/2011, at 12: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.
I have looked at the C libvirt source code a bit, and it seems like libvirt does not support defining guest os type using XML description yet.
Ouch, that sounds less than optimal.
Is there any way I can set the guest OS type for my VM?
I'm not a Python programmer, but wondering if you'd be able to cheat by looking how virt-manager does it?
http://virt-manager.org/scmrepo.html
Virt-manager uses Mercurial for source control, which unfortunately I don't know how to work with either, so can't point you directly to the right file to check.
But, if you want to look, you should be able to check out the repository (however Mercurial does it) and then find the right code pretty fast.
Is that helpful?
Regards and best wishes,
Justin Clift
virt-install/virt-manager allow you to pick a guest OS type and variant to select other config options based on that, but the selection is not passed down to the libvirt level. So it doesn't help to look for this in the virt-install/virt-manager source code :) Matthias
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. 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.
I have looked at the C libvirt source code a bit, and it seems like libvirt does not support defining guest os type using XML description yet.
Is there any way I can set the guest OS type for my VM?
You are indeed correct that this will need an XML extension proposed and coded up to support annotating this into the XML description of a VM. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
2011/1/12 Eric Blake <eblake@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
[adding Richard Jones, as he is more familiar with OS inspection] On 01/12/2011 03:29 PM, Matthias Bolte wrote:
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 ...
I imagine it should either be via some sort of .xml file (similar to libvirt's cpu_map.xml used for determining valid cpu models), or via linking in a common shared library that can share the work among multiple clients. IIRC, there is work under way to provide a library to standardize on detection and description of various operating systems installed in a guest, but I cannot seem to quickly find a reference to such a library at the moment. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Wed, Jan 12, 2011 at 03:51:04PM -0700, Eric Blake wrote:
[adding Richard Jones, as he is more familiar with OS inspection]
On 01/12/2011 03:29 PM, Matthias Bolte wrote:
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 ...
I imagine it should either be via some sort of .xml file (similar to libvirt's cpu_map.xml used for determining valid cpu models), or via linking in a common shared library that can share the work among multiple clients. IIRC, there is work under way to provide a library to standardize on detection and description of various operating systems installed in a guest, but I cannot seem to quickly find a reference to such a library at the moment.
The library is libosinfo: https://fedorahosted.org/libosinfo/ http://git.fedorahosted.org/git/?p=libosinfo.git;a=summary Despite patchy development efforts by several people, it hasn't really gained much traction. I'm not even sure if we are using it in libvirt or virt-manager which was the original intent. For virt-inspector we classify OSes very simply using two text strings: http://libguestfs.org/virt-inspector.1.html#_operatingsystem_ <name> (which corresponds to http://libguestfs.org/guestfs.3.html#guestfs_inspect_get_type in the API) is "linux" or "windows". <distro> (http://libguestfs.org/guestfs.3.html#guestfs_inspect_get_distro) is one of a small set of distro strings. I don't know the best way to do what you want, but I will say there are many different aspects to inspection, and one size won't fit all. For example: - OS type - OS distro - installer location - how to download and install - preferred devices to expose to a new installation - does it support virtio? - what applications are installed in a particular instance? - what device drivers are installed in a particular instance? - licensing requirements Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
2011/1/13 Richard W.M. Jones <rjones@redhat.com>:
On Wed, Jan 12, 2011 at 03:51:04PM -0700, Eric Blake wrote:
[adding Richard Jones, as he is more familiar with OS inspection]
On 01/12/2011 03:29 PM, Matthias Bolte wrote:
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 ...
I imagine it should either be via some sort of .xml file (similar to libvirt's cpu_map.xml used for determining valid cpu models), or via linking in a common shared library that can share the work among multiple clients. IIRC, there is work under way to provide a library to standardize on detection and description of various operating systems installed in a guest, but I cannot seem to quickly find a reference to such a library at the moment.
The library is libosinfo:
https://fedorahosted.org/libosinfo/ http://git.fedorahosted.org/git/?p=libosinfo.git;a=summary
Despite patchy development efforts by several people, it hasn't really gained much traction. I'm not even sure if we are using it in libvirt or virt-manager which was the original intent.
For virt-inspector we classify OSes very simply using two text strings:
http://libguestfs.org/virt-inspector.1.html#_operatingsystem_
<name> (which corresponds to http://libguestfs.org/guestfs.3.html#guestfs_inspect_get_type in the API) is "linux" or "windows".
<distro> (http://libguestfs.org/guestfs.3.html#guestfs_inspect_get_distro) is one of a small set of distro strings.
I don't know the best way to do what you want, but I will say there are many different aspects to inspection, and one size won't fit all. For example:
- OS type - OS distro - installer location - how to download and install - preferred devices to expose to a new installation - does it support virtio? - what applications are installed in a particular instance? - what device drivers are installed in a particular instance? - licensing requirements
Rich.
Actually, for the ESX/VMware and VirtualBox driver I don't really care about detailed OS inspection, I think. The initial point was that some hypervisors allow to specify OS type and distro in order to enable OS dependent stuff like optimizations and workarounds. But libvirt currently doesn't allow you to specify this in the XML config in order to pass this information to the driver. FYI, here's a (probably incomplete) list of guest OS types used by VMware: http://sanbarrow.com/vmx/vmx-guestos.html Matthias
On Thu, Jan 13, 2011 at 09:50:52AM +0100, Matthias Bolte wrote:
Actually, for the ESX/VMware and VirtualBox driver I don't really care about detailed OS inspection, I think. The initial point was that some hypervisors allow to specify OS type and distro in order to enable OS dependent stuff like optimizations and workarounds. But libvirt currently doesn't allow you to specify this in the XML config in order to pass this information to the driver.
FYI, here's a (probably incomplete) list of guest OS types used by VMware: http://sanbarrow.com/vmx/vmx-guestos.html
libvirt goes about this in a different way: it expects the higher level management tool to choose the right devices for the new guest (which is essentially what virt-manager / virt-install do when you give them the OS hint). It's probably impossible from the ESX driver itself, but you could run virt-inspector on the domain and translate the result into a suitable guestOS string. virt-inspector supports a large proportion of the OSes listed. I agree with what you said earlier: this either needs to be modelled explicitly in libvirt, or else you can add an esx:-specific XML namespace to carry this extra data. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
2011/1/13 Richard W.M. Jones <rjones@redhat.com>:
On Thu, Jan 13, 2011 at 09:50:52AM +0100, Matthias Bolte wrote:
Actually, for the ESX/VMware and VirtualBox driver I don't really care about detailed OS inspection, I think. The initial point was that some hypervisors allow to specify OS type and distro in order to enable OS dependent stuff like optimizations and workarounds. But libvirt currently doesn't allow you to specify this in the XML config in order to pass this information to the driver.
FYI, here's a (probably incomplete) list of guest OS types used by VMware: http://sanbarrow.com/vmx/vmx-guestos.html
libvirt goes about this in a different way: it expects the higher level management tool to choose the right devices for the new guest (which is essentially what virt-manager / virt-install do when you give them the OS hint).
Yes, I'm aware of that.
It's probably impossible from the ESX driver itself, but you could run virt-inspector on the domain and translate the result into a suitable guestOS string. virt-inspector supports a large proportion of the OSes listed.
That won't work in general, as you want to set the guest OS type in the VMX config before you install the guest OS. Matthias
On Thu, Jan 13, 2011 at 12:47:34PM +0100, Matthias Bolte wrote:
2011/1/13 Richard W.M. Jones <rjones@redhat.com>:
It's probably impossible from the ESX driver itself, but you could run virt-inspector on the domain and translate the result into a suitable guestOS string. virt-inspector supports a large proportion of the OSes listed.
That won't work in general, as you want to set the guest OS type in the VMX config before you install the guest OS.
So you're stuck with modelling it in the libvirt XML somehow. I will just add that a current RFE is to make virt-inspector work on install CDs. The idea is in virt-manager that we have it automatically fill in the OS hints based on the ISO you try to use. For more information see: http://libguestfs.org/TODO.txt # section "live CD inspection" Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
On Thu, Jan 13, 2011 at 11:54:11AM +0000, Richard W.M. Jones wrote:
On Thu, Jan 13, 2011 at 12:47:34PM +0100, Matthias Bolte wrote:
2011/1/13 Richard W.M. Jones <rjones@redhat.com>:
It's probably impossible from the ESX driver itself, but you could run virt-inspector on the domain and translate the result into a suitable guestOS string. virt-inspector supports a large proportion of the OSes listed.
That won't work in general, as you want to set the guest OS type in the VMX config before you install the guest OS.
So you're stuck with modelling it in the libvirt XML somehow.
I will just add that a current RFE is to make virt-inspector work on install CDs. The idea is in virt-manager that we have it automatically fill in the OS hints based on the ISO you try to use.
What we're trying todo with libosinfo is to kind of reverse the current approach, so we don't need any probing at all. The libosinfo database will actually contain metadata about where the install media can be obtained (admin specified local ISO/URL paths, and/or some default internet URL install paths, etc). Currently virt-manager asks the user to fill in a ISO path or URL for their OS, and then probes it to find out what type of OS. With libosinfo integrated, the user would simply be shown a list of OS, and pick one off the list. Then virt-manager would query libosinfo to find out the URL/ISO path and all the hardware support metadata associated with it without needing to probe. libosinfo is also designed to allow us to distinguish officially supported deployments, from the larger set of technically possible deployments. The latter is simply the intersection of hardware support list of the current HV, with the hardware support list of the chosen OS. The 'supported deployments' will artificially restrict that intersection to a smaller set of hardware. This is useful for enterprise distros which want to given prominence to OS/HV configurations that have been strictly validated by QA, while at the same time not forcably disabling other configurations. So eg validated deployments configs for RHEL6 KVM could be listed as Win2k + virtio, RHEL5 + virtio, RHEL6 + virtio. The libosinfo database would also show possible alternative configs of Win2k + SCSI, RHEL-5 + IDE, RHEL5 + SCSI, Solaris 10 + IDE, etc Regards, Daniel
On Thu, Jan 13, 2011 at 12:45:30PM +0000, Daniel P. Berrange wrote:
On Thu, Jan 13, 2011 at 11:54:11AM +0000, Richard W.M. Jones wrote:
On Thu, Jan 13, 2011 at 12:47:34PM +0100, Matthias Bolte wrote:
2011/1/13 Richard W.M. Jones <rjones@redhat.com>:
It's probably impossible from the ESX driver itself, but you could run virt-inspector on the domain and translate the result into a suitable guestOS string. virt-inspector supports a large proportion of the OSes listed.
That won't work in general, as you want to set the guest OS type in the VMX config before you install the guest OS.
So you're stuck with modelling it in the libvirt XML somehow.
I will just add that a current RFE is to make virt-inspector work on install CDs. The idea is in virt-manager that we have it automatically fill in the OS hints based on the ISO you try to use.
What we're trying todo with libosinfo is to kind of reverse the current approach, so we don't need any probing at all. The libosinfo database will actually contain metadata about where the install media can be obtained (admin specified local ISO/URL paths, and/or some default internet URL install paths, etc). Currently virt-manager asks the user to fill in a ISO path or URL for their OS, and then probes it to find out what type of OS. With libosinfo integrated, the user would simply be shown a list of OS, and pick one off the list. Then virt-manager would query libosinfo to find out the URL/ISO path and all the hardware support metadata associated with it without needing to probe.
libosinfo is also designed to allow us to distinguish officially supported deployments, from the larger set of technically possible deployments. The latter is simply the intersection of hardware support list of the current HV, with the hardware support list of the chosen OS. The 'supported deployments' will artificially restrict that intersection to a smaller set of hardware. This is useful for enterprise distros which want to given prominence to OS/HV configurations that have been strictly validated by QA, while at the same time not forcably disabling other configurations. So eg validated deployments configs for RHEL6 KVM could be listed as Win2k + virtio, RHEL5 + virtio, RHEL6 + virtio. The libosinfo database would also show possible alternative configs of Win2k + SCSI, RHEL-5 + IDE, RHEL5 + SCSI, Solaris 10 + IDE, etc
Oh, but virt-inspector will still be quite useful. It could be used to make the task of populating the libosinfo database of OS alot faster and largely automated. eg given a new release ISO from a vendor, the list of all possible devices supported by the OS can be automaticlaly extracted by virt-inspector (for Linux by calling modinfo on every kernel module & scraping the PCI alises), and then written into the libosinfo DB. The only manual step would then be deciding which os those possible devices should be marked as part of the 'validated deployment' set for a particular OS,HV pairing. Daniel
On Thu, Jan 13, 2011 at 12:55:27PM +0000, Daniel P. Berrange wrote:
the list of all possible devices supported by the OS can be automaticlaly extracted by virt-inspector (for Linux by calling modinfo on every kernel module & scraping the PCI alises),
Intelligent use of modinfo is an RFE for libguestfs / virt-inspector too ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
Agreed. Sounds very good, even though it might take sometime to be accomplished. I will hack the vmx configuration file for now and wait for the updates. Thanks everyone for making such useful libraries/tools. On Thu, Jan 13, 2011 at 5:07 AM, Richard W.M. Jones <rjones@redhat.com>wrote:
On Thu, Jan 13, 2011 at 12:55:27PM +0000, Daniel P. Berrange wrote:
the list of all possible devices supported by the OS can be automaticlaly extracted by virt-inspector (for Linux by calling modinfo on every kernel module & scraping the PCI alises),
Intelligent use of modinfo is an RFE for libguestfs / virt-inspector too ...
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Jan 13, 2011 at 12:45:30PM +0000, Daniel P. Berrange wrote:
On Thu, Jan 13, 2011 at 11:54:11AM +0000, Richard W.M. Jones wrote:
On Thu, Jan 13, 2011 at 12:47:34PM +0100, Matthias Bolte wrote:
2011/1/13 Richard W.M. Jones <rjones@redhat.com>:
It's probably impossible from the ESX driver itself, but you could run virt-inspector on the domain and translate the result into a suitable guestOS string. virt-inspector supports a large proportion of the OSes listed.
That won't work in general, as you want to set the guest OS type in the VMX config before you install the guest OS.
So you're stuck with modelling it in the libvirt XML somehow.
I will just add that a current RFE is to make virt-inspector work on install CDs. The idea is in virt-manager that we have it automatically fill in the OS hints based on the ISO you try to use.
What we're trying todo with libosinfo is to kind of reverse the current approach, so we don't need any probing at all. The libosinfo database will actually contain metadata about where the install media can be obtained (admin specified local ISO/URL paths, and/or some default internet URL install paths, etc). Currently virt-manager asks the user to fill in a ISO path or URL for their OS, and then probes it to find out what type of OS. With libosinfo integrated, the user would simply be shown a list of OS, and pick one off the list. Then virt-manager would query libosinfo to find out the URL/ISO path and all the hardware support metadata associated with it without needing to probe. [...]
I agree this is a better approach. It's what we did with virt-ctrl back in the day :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On Wed, Jan 12, 2011 at 03:16:00PM -0700, Eric Blake wrote:
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.
Well libguestfs itself likely needs to inspect the disk every time (eg. the operating system might have been upgraded since last time). Also we don't necessarily have libvirt around - we can be asked to inspect a raw disk image. However I know that there was someone asking me if the inspection data could be cached in the libvirt XML so that they could query it out quickly later on. Unfortunately I forget now who asked me this and which project wanted it (maybe Chris Lalancette??). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
Thanks everyone. It's time to go home now. I will finish reading the thread and respond later. Jake On Wed, Jan 12, 2011 at 4:09 PM, Richard W.M. Jones <rjones@redhat.com>wrote:
On Wed, Jan 12, 2011 at 03:16:00PM -0700, Eric Blake wrote:
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.
Well libguestfs itself likely needs to inspect the disk every time (eg. the operating system might have been upgraded since last time). Also we don't necessarily have libvirt around - we can be asked to inspect a raw disk image.
However I know that there was someone asking me if the inspection data could be cached in the libvirt XML so that they could query it out quickly later on. Unfortunately I forget now who asked me this and which project wanted it (maybe Chris Lalancette??).
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
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
2011/1/13 Daniel P. Berrange <berrange@redhat.com>:
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.
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.
Actually other-64 is on of the VMware guest OS types. The VMX code uses "other" or "other-64" based on the given architecture of the guest, because the guestOS entry is mandatory. Matthias
On Thu, Jan 13, 2011 at 01:06:00PM +0100, Matthias Bolte wrote:
2011/1/13 Daniel P. Berrange <berrange@redhat.com>:
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.
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.
Actually other-64 is on of the VMware guest OS types. The VMX code uses "other" or "other-64" based on the given architecture of the guest, because the guestOS entry is mandatory.
Ah, well virt-install has a similar generic option. Daniel
2011/1/13 Daniel P. Berrange <berrange@redhat.com>:
On Thu, Jan 13, 2011 at 01:06:00PM +0100, Matthias Bolte wrote:
2011/1/13 Daniel P. Berrange <berrange@redhat.com>:
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
2011/1/11 Jake Xu <jake@demonwaremail.net>:
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. I have looked at the C libvirt source code a bit, and it seems like libvirt does not support defining guest os type using XML description yet.
That's correct, currently there is no way to pass guest OS type/variant information to the ESX driver, as the domain XML config doesn't include such information.
Is there any way I can set the guest OS type for my VM?
Unfortunately you can only select between 32 and 64bit guests at the moment. But that should work for most guest OS types anyway. On the other hand it might be important for some guest OS types might to be set correctly because ESX might enable special optimizations or workarounds for them. This sits is on my todo list since a while now, but I didn't figure out a proper solution yet. One option would be to add an guest OS type/variant element to the domain XML config, but that would only be useful for the ESX and the VirtualBox driver. Another option would be to add an esx (or actually vmware) namespace extension to the domain XML config as we currently have for arbitrary qemu commandline arguments. Matthias
On Wed, Jan 12, 2011 at 11:20:42PM +0100, Matthias Bolte wrote:
2011/1/11 Jake Xu <jake@demonwaremail.net>:
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. I have looked at the C libvirt source code a bit, and it seems like libvirt does not support defining guest os type using XML description yet.
That's correct, currently there is no way to pass guest OS type/variant information to the ESX driver, as the domain XML config doesn't include such information.
IIUC, VMWare doesn't actually want a type/variant split. That split is only something that is used in the UI. The actual VMX file just uses a single short string to identify the OS. Daniel
participants (6)
-
Daniel P. Berrange -
Eric Blake -
Jake Xu -
Justin Clift -
Matthias Bolte -
Richard W.M. Jones