On Sun, Jun 24, 2007 at 05:33:10PM +0100, Richard W.M. Jones wrote: > [I haven't implemented any of these yet, but if people think they're a > good idea, or at least not an actively bad idea, then I'll post a patch.] > > virDomainGetConnection > virNetworkGetConnection > > Purpose: Given a virDomainPtr or virNetworkPtr, obtain the virConnectPtr. > > Reason: All the language bindings to libvirt need to keep the > virConnectPtr separately alongside the virDomain/NetworkPtr, in the main > so that they can query if an error has happened from inside some deep > call. This is wasteful since the connection pointer is already included > in the virDomain or virNetwork structure, so we should just provide a > call to get it. Yep that would be handy. In virt-manager we create a wrapper around the libvirt python virDomainPtr object, to add extra methods - one of which is to get the python virConnectPtr object back. So this would be handy to have in the base library API. > virConnectGetHostname > virConnectGetTransport > virConnectGetURI > > Purpose: Get the remote hostname, remote transport (tls, ssh, etc.), > and URI. > > Reason: In virt-manager it would be nice to display the remote > hostname. However doing this at the moment requires parsing the > connection URI, which is duplicated code and also significantly > complicated. Instead, allow the remote driver to just give us this > information, and in non-remote cases default to something sensible. The > case for the other two calls is weaker, but it might still be useful to > know something about the security of the actual transport selected, and > also to not have to keep the URI around with the connection (we might > also canonicalise the transport for the user). Yep, these would be very useful too - particularly if the driver were to canonicalize the URI. Again in the virt-manager wrapper around the base virDomainptr python object we add in a method to get a URI, and get the hostname associated with the URI. > virConnectPing > > Purpose: "Ping" the hypervisor to see if its up. > > Reason: Since we now support remote connections, there is a much more > signficant chance that we will lose contact with the hypervisor, for > example if the host goes down. This will do some very minimal operation > to cheaply test whether the hypervisor can be contacted. Of course we > could do something like 'virConnectNumOfDomains', but it's not clear to > me that this operation would always be cheap (eg. if we had to implement > it through xend). Not sure about whether we need this - yet - at least in the virt-manager use case we are periodically calling virConnectNumOfDomains anyway just to get status updates. This in effect provides us a 'ping'. If we ever add an API to get asynchronous notification of domains being created/destroyed then we would no longer have to poll periodically - at which point a 'ping' method would become useful 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 -=|