On Wed, Apr 02, 2008 at 02:05:58AM +0100, Daniel P. Berrange wrote:
>
> The following document illustrates an API for host device enumeration,
> creation and deletion. This has a number of use cases:
[...]
> This all sounds like alot of data / stuff to manage, but the good news
> is that there is already an application which does most of this for
> us. ie HAL. So at the basic level all we need to do is map the HAL
> properties into a libvirt XML format for describing devices.
Having gone though the description a couple of time, this makes sense
to me I just have a couple of remarks:
- basically we are now extending libvirt to be a generic accessor
for host physical data it's fine because we need it but ...
- if hald daemons (I have 5 hal related daemons running mon my F8
desktops) had exported things in a secure way most of this would not
be needed, right ?
But having a remote secure way to access hardware data is needed, if libvirt
is the first one to provide it, why not ! It will certainly make things
easier for libvirt users.
> I have chosen to define a very direct mapping.
Agreed, no need to remap, basically the only thing really hal specific
in the exposed XML data are the hal names, which are basically internal
unique names for addressing the devices, and public names usable for
user comminication are also available so that's fine.
[...]
> Now some example XML descriptions....
[..]
>
> Notice how the specific functional devices like NICs, HBAs, are
> children of the physical USB or PCI device. This is where the
> hierarchy comes in.
Well except the hierarchy is not reflected at the XML structure level.
But I understand we need to be able to isolate devices descriptions and
this could get too complex to be represented by a tree, so that's fine.
> There are a few other types of devices we want explicit representations
> for, block devices, sound devices, storage devices, input devices. I
> want describe them here, but they follow same pattern of mapping the
> XML onto the HAL properties in their <capability> tags.
>
> There are some devices HAL does not represent so we'll have to augment
> the HAL information. Specifically devices which don't correspond to
> a physical device, eg
>
> - Bonding NICs
> - Bridges
> - VLANs
how much of that could be separated and considered a local network
topology and extracted with the network APIs instead ?
> The API to deal with this is really very simple. APIs to query all
> devices, or query devices based on a capability, or bus type:
>
>
> int
> virNodeNumOfDevices(virConnectPtr conn)
>
> int
> virNodeListDevices(virConnectPtr conn,
> char **const names,
> int maxnames)
I would add a flags for future extensibility of those 2 entry points.
For example to be able to query 'active' devices.
> int
> virNodeNumOfDevicesByCap(virConnectPtr conn,
> const char *cap)
>
> int
> virNodeListDevicesByCap(virConnectPtr conn,
> const char *cap,
> char **const names,
> int maxnames)
How do you know the proper values for cap (or bus below) ?
> int
> virNodeNumOfDevicesByBus(virConnectPtr conn,
> const char *bus)
> int
> virNodeListDevicesByBus(virConnectPtr conn,
> const char *bus,
> char **const names,
> int maxnames)
Okay that's server side filtering why not make it a bit more generic ?
int
virNodeNumOfDevicesSubset(virConnectPtr conn,
const char *selector);
int
virNodeListDevicesSubset( virConnectPtr conn,
const char *selector,
char **const names,
int maxnames)
where the selector could be something like:
bus='usb'
cap='net'
bus='pci' and cap='net'
To me the problem may quickly become to filter the available informations
while still allowing the API to be 1/ extensive 2/ fast (limited round trip)
when you know what you want.
Ultimately, you may want to move a domain from one machine with a very
specific kind of device to another one in the pool with the same hardware
(and not used yet by a running domain), and querying for this may need
a relatively specific selector, that's why I think just selecting on bus
or on capability may not be sufficient.
Maybe HAL has better API for this.
Maybe that's too complex but even with the existing API I think you need
to be able to enumerate the bus and capability values to avoid hardcoding
in the application HAL specific knowledge.
>
> Then APIs to obtain a virNodeDevicePtr object corresponding to a
> device name / key :
>
> virNodeDevicePtr
> virNodeDeviceLookupByName(virConnectPtr conn, const char *name)
>
> virNodeDevicePtr
> virNodeDeviceLookupByName(virConnectPtr conn, const char *key)
you mean virNodeDeviceLookupByKey there
> int
> virNodeDeviceFree(virNodeDevicePtr dev)
>
>
> An API to get the XML description:
>
> char *
> virNodeDeviceDumpXML(virConnectPtr conn,
> unsigned int flags)
>
>
>
> Finally an API to create / delete devices - this is only for devices
> with certain capabilities
>
> virNodeDevicePtr
> virNodeDeviceCreate(virConnectPtr conn,
> const char *xml)
>
> int
> virNodeDeviceDestroy(virNodeDevicePtr dev)
Except for the querying capability this sounds fine to me. Of course
at some point people may need change informations lookup (I'm not sure
we want to provide a callback based API, something querying for changes
since last check might be more useful state could be preserved in the
libvirtd).
> I don't propose to expose all the data - only specific properties we have
> immediate need for. The HAL spec describes the meaning of various props
The only thing I would like to avoid is that the immediate need viewpoint
to lead to an API which we would have to modify and deprecate once used
for a couple of years :-)
But as-is except the mechanism for server side list filtering this looks
just right to me,
thanks !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list