[fedora-virt] RFC: libosinfo: Library for virt OS/distro metadata 3
Cole Robinson
crobinso at redhat.com
Sun Jun 14 22:50:02 UTC 2009
Hi all,
I've done the initial work for a new library, libosinfo (better name
recommendations appreciated). This library will provide OS meta data for use
in virt applications, replacing the dictionary we currently keep in virtinst.
This is based off of a post by Dan Berrange:
https://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00028.html
The code can be fetched with:
git clone http://fedorapeople.org/~crobinso/osinfo/.git
Check out the TODO list for a simple roadmap.
http://fedorapeople.org/~crobinso/osinfo/TODO
The public API looks like:
/**
* Values stored in the OS dictionary
*/
enum _os_value_type {
OS_VALUE_NAME = 1, /** Human readable family/distro... name */
OS_VALUE_MEDIA_INSTALL_URL, /** URL to an install tree */
};
typedef enum _os_value_type os_value_t;
int os_init();
void os_close();
int os_find_families (char ***list);
int os_find_distros (const char *parent_id, char ***list);
int os_find_releases (const char *parent_id, char ***list);
int os_find_updates (const char *parent_id, char ***list);
int os_lookup_value (os_value_t value_type,
const char *os_id,
char **value);
The unique identifier for each distro is its 'id', which is a simple human
readable string, similar to values we use for virt-install --os-variant today.
The user will ask the API for available families/distros/releases/updates,
which will return a list of ids. We then pass an id to os_lookup_value to
actually retrieve data. The family/distro/... separation will likely be
removed pretty soon, in favor of an arbitrary hierarchy, where every OS
can have child OSes: no doubt hardcoding the family/distro/... split would
come back to bite us in the ass.
As an example, the following code will list the 'Name' of every id at
the'family' level, where name is full name of the OS (id = rhel5.3, name = Red
Hat Enterprise Linux 5.3):
char *value = NULL;
char **namelist = NULL;
int i, num_fams;
if (os_init() < 0)
goto error;
if ((num_fams = os_list_families(&namelist)) < 0)
goto error;
for (i = 0; i < num_fams; ++i) {
if (os_lookup_value(OS_VALUE_NAME,
namelist[i],
&value) < 0)
goto error;
printf("%s\n", value);
free(value);
}
error:
free(namelist);
free(value);
os_close();
There is a simple tool called 'osinfo-tool' which allows listing an ASCII repr
of the OS hierarchy, and listing all values for an individual id (which is
pretty sparse at the moment since most of these values haven't been filled
in yet).
So, things that I'm interested in feedback on:
- How do we expect apps to list OS choices? Currently, virt-manager lists
type (linux, windows, unix, etc.) and associated distros (Fedora 8, RHEL4,
Debian Lenny, etc.). The linux/windows/unix info isn't represented in the
xml (should it be?) so the best way seems to be:
Distro
|
--> Release
|
--> Update
Ex.
RHEL
|
-> RHEL5
|
-> 5.0
5.1
5.2
If we do away with the family/distro/... distinction, the user won't have
much choice in the matter, but the 'family' concept (e.g. value of
'Red Hat') isn't very useful to expose to a user.
- How should we handle derivatives like Scientific Linux + CentOS: should we
expect users to understand they are based on RHEL, or give them explicit
IDs?
- Querying for device values (supported buses, models, etc.). Dan's original
proposal talks about this; to recommend a default with the best chance of
actually working, we need to know:
- OS being installed
- Virt type ('hvm' vs. 'xen')
- Guest Architecture (i386, x86_64, ...)
- Hypervisor (kvm, qemu, xen, vbox, ...)
- Hypervisor version
- Libvirt version
We would need to find the intersection of what the OS, the hypervisor,
and libvirt support, and return what we decide is the best choice.
How to expose this in the API? We could simply have one long function
os_lookup_device_value(char *os_id, char *virt_type, char *arch, ...)
It works, but its pretty tedious, and I'm afraid that we would need
even more info to make a correct choice in the future, and the above
isn't flexible. We may also need some of the above info for other values
(ACPI/APIC settings, returning a proper install url may depend on arch).
Any suggestions?
- os_init and os_close: Any better ideas for this? os_init just parses the
xml document, os_close frees it. We could run os_init with the first API
call, but I think that makes it less clear that the user would then
need to call os_close().
Any feedback appreciated.
Thanks,
Cole
More information about the Fedora-virt
mailing list