[Libvir] Useful additional functions for libvirt
Daniel P. Berrange
berrange at redhat.com
Sun Jun 24 18:59:11 UTC 2007
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.]
> 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.
> 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.
> 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
|=- 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 -=|
More information about the libvir-list