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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/