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(a)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