[Libvir] Useful additional functions for libvirt

[Daniel P. Berrange]

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  -=|