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