Daniel Veillard wrote:
You seems to think it's useful only for migrate. I want that to
be
usable for a lot more.
Examples being ...? I want to know if there's a real example where a
coordinating function would like to query > 1 feature of the underlying
driver, and if doing so save signicant numbers of round trips in the
remote case.
You talk to a remote server, you want to know if
it supports any of the entry point in the driver table, how do you do this ?
I don't claim that it can do this. In the original design I looked at
how one might do this and concluded it was pretty difficult. You can't
just use indexes into the driver structure because they change depending
on architecture and packing rules[1].
> On the other hand, it complicates the interface. You need to
return an
> array rather than a single int. (OK, so you can return a bit array, but
> now the feature list had better always be <= 32 entries long). And in
> the case where someone queries VIR_DRV_FEATURE_MIGRATE_V1 &
> VIR_DRV_FEATURE_REMOTE you need to have two different drivers answering
> a single request.
>
> I think this complicates things unnecessarily ...
I think this would be a waste to design it with a single narrowly focused
usage in mind, when it can be far more generally useful.
and Dan Berrange wrote:
Yes - as a concrete example - QEMU driver doesn't support
save/restore. We
have no way to find this out in virt-manager without actually trying to run
the API & wait for it to fail. If we could query libvirt to ask if the driver
supported a particular feature, we could disable the save/restore buttons/menus
in virt-manager.
That is another thing though.
The patch I gave is an internal libvirt.c -> driver API to replace
occasions when we might do "if (drv->some_func != NULL) { ... }".
What you're talking about is already supported through
virConnectGetCapabilities -- a public function which allows libvirt
users to query specific capabilities of the underlying hypervisor, eg.
do we support save/restore?
Rich.
[1] See discussion of "is_available" macro here:
https://www.redhat.com/archives/libvir-list/2007-July/msg00437.html
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903