[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Useful additional functions for libvirt



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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]