On Sat, May 05, 2007 at 12:00:49PM +0100, Richard W.M. Jones wrote:
> OK so this is step 2.5 out of 8 ... it wasn't part of the original plan.
>
> 2.5 Export virGetDomain and virGetNetwork
> -----------------------------------------
>
> M src/libvirt_sym.version
> M src/hash.c
> M src/internal.h
>
> This patch exports virGetDomain and virGetNetwork functions as
> "internal" functions (__virGetDomain and __virGetNetwork) for use by the
> remote daemon.
>
> The use is as follows: client needs to invoke a function such as
> virDomainSuspend (virDomainPtr dom). In order to do this it has to send
> a reference to "dom" over the wire to the server, which it does by
> encoding a remote_nonnull_domain XDR object (basically the name and
> UUID). On the server side we use virGetDomain to pull out the
> corresponding virDomainPtr from the hash associated with the connection.
Looks reasonable. The only other alternative would be to explicitly
lookup a domain by UUID on every call, eg
dom = virDomainLookupByUUID(uuid)
..do the work...
virDomainFree(dom)
The virConnectPtr object has these objects cached so it wouldn't
neccessarily be any slower this way. It would have the downside
of slight semantic change - LookupByUUID may actually hit the
undering XenD apis if the cache was empty. This may make for hard
to debug problems & complicate error reporting. So, I think it is
reasonable to export virGetDomain & virGetNetwork to allow direct
use of the cache in this scenario.
Dan,
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|