[et-mgmt-tools] [PATCH] Add --list-os-options to virt-install and virt-convert

[Daniel P. Berrange]

On Mon, Mar 02, 2009 at 07:57:38PM -0500, John Levon wrote:
> On Mon, Mar 02, 2009 at 07:24:41PM -0500, Cole Robinson wrote:
> 
> > Do you think it should be in all relevant man pages (virt-convert,
> > virt-image, virt-install) or just have the other two link back to
> > virt-install?
> 
> Just the one please :)
> 
> Any thought been given to moving all of osdict into a system-installed
> XML file? The parameters of how different operating systems behave are
> only going to get more complex. Note that OVF will need a similar (in
> fact, most likely more complex) database for the virtual platforms.

Absolutely, this is the long term approach we want to take for a number
of reasons. There's quite a few things I don't like about how we are
currently handling it

 - It is not possible for local admins to change / extend it, eg to
   add new OS distribution release. It is guarenteed to be out of date
   almost as soon as each new virtinst release ships, due to frequency
   of new OS distros. This is particularly bad for RHEL with its 6 month
   cycle between update releases

 - It is tied into virt-install & apps based on it. This makes it hard
   to use from Cobbler, oVirt,  VMWare, or any other virt provisioning
   tool that's not using virt-install python APIs

 - It does not include enough information. Type + variant are not really
   sufficient. RHEL-5 has updates where new capabilities appear like
   virt IO. We really need at least a 4 level grouping for some OS, eg
   family (Red Hat), distro (RHEL), release (RHEL5), update (RHEL-5.3).

 - It ignores the installation URL information. When doing net installs
   user has to specify URL to download.fedora.redhat.com and virtinstall
   has the fragile probing to validate this. The OS metadata could easily
   include the mirror URLs for any free distro


Todo a better job there's several things I want todo with this:

 - An XML schema for defining all the information wrt to guest OS distros
   that is relevant to virt management tools.

 - A C library for querying the information in the XML file(s).

 - Bindings of the C library into Python/Ruby etc as needed

 - Ability for local admins to extend / override the information either
   by editing the XML files directly, or a pretty GUI


The XML schema is the really important thing, but I think it'd be very
important to have a API around it and not expect apps to read the XML
directly. This is because to get sufficient flexibility without huge
amounts of duplication, I think we'll need to try and keep the XML doc
highly normalized, and not just a plain tree - think more of a structure
like RDF where there are many tree's cross-referencing each other.

I'm attaching an example XML doc I knocked up a few months ago, but I'm
not really happy with it as is. In particular I think rather than trying
todo a explicit 4 level (family, disto, release, update) hierarchy, it
should just be doing an arbitrary generic nested structure, without
imposing specific terminology on each level - there's just too much 
difference between the OS out there.

The representation of supported drivers isn't all that great either - albeit
better than current way. I was trying to keep two lists - sets of configs
inheriting from each other, and refernce them from OS distros. This doesn't
capture the full horror of the combinations in the real world though. I
feel it might be better to try and maintain an explicit list of emulated
devices per (hypervisor, release), and an explicit list of supported 
device drivers per (os distro, release), then compute the intersection.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: README.xml
Type: text/xml
Size: 1899 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20090303/ff293483/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osinfo.xml
Type: text/xml
Size: 4653 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20090303/ff293483/attachment-0001.xml>