[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Remote patch, 2007-02-28

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:

  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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]