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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list