This patch adds two calls:
/**
+ * virConnectGetHostname:
+ * @conn: pointer to a hypervisor connection
+ *
+ * This returns the system hostname on which the hypervisor is
+ * running (the result of the gethostname(2) system call). If
+ * we are connected to a remote system, then this returns the
+ * hostname of the remote system.
+ *
+ * Returns the hostname which must be freed by the caller, or
+ * NULL if there was an error.
+ */
+char *
+virConnectGetHostname (virConnectPtr conn)
and:
+/**
+ * virConnectGetURI:
+ * @conn: pointer to a hypervisor connection
+ *
+ * This returns the URI (name) of the hypervisor connection.
+ * Normally this is the same as or similar to the string passed
+ * to the virConnectOpen/virConnectOpenReadOnly call, but
+ * the driver may make the URI canonical. If name == NULL
+ * was passed to virConnectOpen, then the driver will return
+ * a non-NULL URI which can be used to connect to the same
+ * hypervisor later.
+ *
+ * Returns the URI string which must be freed by the caller, or
+ * NULL if there was an error.
+ */
+char *
+virConnectGetURI (virConnectPtr conn)
It also fixes a kind of accidental memory leak which turns out not to be
a memory leak. In the current version of libvirt CVS, when using remote
connections, remote's private data is not freed by remote_internal.c.
However it turns out that it _is_ freed by qemuNetworkClose. Obviously
some confusion there, but this patch fixes that. (Fixing that is a
dependency of this patch, which is why the two are done together in one
patch).
I've added "virsh hostname" and "virsh uri" commands:
$ src/virsh -c test:///default uri
test:///default
$ src/virsh -c test:///default hostname
localhost.localdomain
(Yeah, I haven't set the hostname on this machine ...)
I've updated the Xen, test and remote drivers to support the calls.
However I didn't update qemu because of Dan's big changes to qemu. Once
we have decided whether to put in Dan's changes, I'll go back and
implement this for qemu. (I'm actually not sure I would need to
implement them, if remote supports the calls already).
I haven't updated the Python bindings, but will do so next.
I decided not to implement the proposed virConnectGetTransport call
because I think it needs more thought. It would obviously be useful to
find out whether the current connection is local or remote, encrypted or
unencrypted, authenticated or unauthenticated, because all of these
things could be usefully communicated back to the user by icons in
virt-manager. Simply returning the transport name doesn't really do
this. The user might also want to find out _how_ the session is
encrypted (what TLS parameters are in use), and again a simple string
can't do that.
Before applying this patch you will need to do:
rm qemud/remote_dispatch_localvars.h \
qemud/remote_dispatch_proc_switch.h \
qemud/remote_dispatch_prototypes.h \
qemud/remote_protocol.c \
qemud/remote_protocol.h
and after applying you will need to do:
make -C qemud remote_protocol.c
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