Mark McLoughlin wrote:
- I'm not sure the libvirt API is really well designed for remote
use, so I'm not sure that mapping the API calls to RPC calls is the
best approach.
The level that is right for abstraction is definitely troubling to me.
For example at the moment it'll work provided that the calls in
libvirt.c map directly on to driver calls. In other words, with a
unified Xen driver, if the functions in libvirt.c turn into:
int
virConnectGetVersion(virConnectPtr conn, unsigned long *hvVer)
{
return conn->driver->version (conn, hvVer);
}
(I've removed some error checking, but that's not material). And that
is kind of what happens at the moment, for most of the functions in
libvirt.c
With this scenario, it seems reasonable to abstract at the driver level,
which is what the remote patch does right now. We can also optimise
calls like ListDomains so that they optimistically pull all the data
over the wire that is needed for subsequent LookupByID calls.
This becomes problematic if the functions in libvirt.c become more
complicated -- for example if a single function maps to several
underlying driver calls (and I haven't really started to look at the
networking code).
e.g. to iterate over the list of domain UUIDs, you need to
ListDomains(), and then for each of them LookupByID() and
GetUUID(). That API might be fine for apps, but libvirt doesn't
necessarily need to map the API calls exactly to RPC calls - e.g.
you could have a ListDomains() RPC call return id/name/uuid tuples
and make LookupByID() and GetUUID() not involve a network
roundtrip[1].
One problem with that is that in order for the remote driver to
know when to invalidate the ListDomains() cache, it needs
asynchronous notification of domain creation. Which I think we want
in the API long term, anyway.
Agreed.
Rich.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
