On Mon, Jun 15, 2009 at 11:09:56AM -0400, Cole Robinson wrote:
> Daniel P. Berrange wrote:
> > On Sun, Jun 14, 2009 at 06:50:02PM -0400, Cole Robinson wrote:
> > For OS distros I think we need APIs to:
> >
> > - List all OS distros
> > - Find OS distros, matching a specific set of properties
>
> What uses do you have in mind for this? Being able to say e.g. 'all
> distros that support xen PV for IA64'?
>
> How do you think an API call would look?
Just a function callback for doing the filtering. If the callback
returned 1 the distro object is kept, otherwise it is discarded.
typedef int (*osfilter-t)(osdistro_t *distro, void *opaque);
osdistro_t **os_distro_find(osinfo_t, osfilter_t filter, void *opaque);
> > - Read a property from an OS distro
> > - Read all properties from an OS distro
>
> Why would an API user want to do this? I don't see why we would need to
> enable this specifically, rather than make the user do this iteratively.
>
> > - List unique values for a property across all distros
> >
>
> Not sure I fully understand this. Why would a user want this?
Imagine virt-manager building a 2 level hiearchy. For the first level
it wants to use this method
- Get a list of uninque vendor names among all known OS distros
eg
char **vendors = os_info_unique_properties(osinfo, "vendor");
Upon selecting a vendor, it then wants the earlier method
- Get a list of all OS distros for that vendor
eg
int vendorfilter(osdistro_t distro, void *opaque) {
char *wantvendor = opaque;
char *gotvendor = os_distro_get_prop(distro, "vendor");
if (gotvendor && STREQ(wantvendor, gotvendor)
return 1;
return 0;
}
osdistro_t *distros = os_distro_find(osinfo, vendorfilter, "Red Hat");
> >>
> >> - 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?
> >
> > The more I think about this, the more I think we should avoid any specific
> > named attributes in the API. Supported devices are just other types of
> > property we can associated with a distro, in addition to ones I already
> > listed earlier. This could be useful in the UI too, for example, if you
> > know the hypervisor requires support for 'Xen paravirt disk', then when
> > browsing OS, you can filter on this property just as you would with the
> > others.
> >
>
> If the app already knows their hypervisor requires 'Xen paravirt disk',
> the above is fine, and we should facilitate filtering like that. However
> I would like osinfo to save the user from having to know those details:
> they should just be able to say 'I'm using xenpv on i386 for xen 1.2.3
> and libvirt 4.5.6 with distro fedora10' and osinfo can return the
> required info. So I still don't see how to solve the above problem.
>
> Let's say we are installing winxp on qemu via libvirt: we want to know
> the recommended sound device model:
>
> winxp prefers ac97, es1370
> qemu supports es1370, if >= 0.10.0, supports ac97
> libvirt supports es1370, if >= 0.6.0 supports ac97
>
> How do we solve this via the API?
The latter 2 questions really say that libvirt needs to export more info
about what a driver has.
For the former, the OS info database needs to somehow provide a list of
drivers available for each OS. Obviously you can take the intersection,
but perhaps also define that they are listed in preferred order, "best"
first.
Perhaps we should be really ambitious and for each OS distro allow for a
full list of PCI device IDs it supports. For linux you can auto-generate
that from the kernel module metadata. You could even imagine that the
distro provide an XML file in our format with this info in their release
media/trees.
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 :|
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
