[Libvir] [PATCH] Add virConnectGetHostname and virConnectGetURI calls, virsh commands, and some related fixes

Richard W.M. Jones rjones at redhat.com
Tue Jun 26 10:09:21 UTC 2007


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvirt-hostname-uri-20070626.patch
Type: text/x-patch
Size: 26355 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070626/5a6c10e4/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070626/5a6c10e4/attachment-0003.bin>


More information about the libvir-list mailing list