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