[libvirt] esx driver: XML format for guest OS type/variant

[Daniel P. Berrange]

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 at 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