11:33 a.m.
[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).
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).
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
1:59 p.m.
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.
Yep that would be handy. In virt-manager we create a wrapper around the
libvirt python virDomainPtr object, to add extra methods - one of which
is to get the python virConnectPtr object back. So this would be handy
to have in the base library API.
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).
Yep, these would be very useful too - particularly if the driver were to
canonicalize the URI. Again in the virt-manager wrapper around the base
virDomainptr python object we add in a method to get a URI, and get the
hostname associated with the URI.
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).
Not sure about whether we need this - yet - at least in the virt-manager use
case we are periodically calling virConnectNumOfDomains anyway just to
get status updates. This in effect provides us a 'ping'. If we ever add
an API to get asynchronous notification of domains being created/destroyed
then we would no longer have to poll periodically - at which point a 'ping'
method would become useful
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
3:16 a.m.
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/
6360
days inactive
6361
days old
2 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones