[Libvir] Useful additional functions for libvirt
Daniel Veillard
veillard at redhat.com
Mon Jun 25 08:16:34 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.]
>
> 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.
>
> 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).
Those all looks fine to me, they make the APIs more connex and reflexive
> 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).
That looks a bit dubious to me, I would rather make sure that we catch
and report disconnection in the best way to avoid the incentive of userland
doing polling. Remote polling is a plague that all network admins fears,
let's make sure we don't need it instead.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list
mailing list