[Libvir] Proposal: New virDomainLookup function to indicate Not found vs Error
by Richard W.M. Jones
virt-install has some code which waits for a domain to appear just after
it has been created. It looks like the loop attached to the end of this
email, and is functional but has two problems.
Problem (1) is that self.conn.lookupByName doesn't distinguish between a
"Not found" domain and an actual error. For example there is no way to
tell the difference between being unable to contact xend (an actual
error), and being able to contact xend, but xend not being able to find
the domain (not found).
As shown here:
>>> import libvirt
>>> conn = libvirt.open ("xen+tls:///")
>>> d = conn.lookupByName ("Domain-0")
>>> d = conn.lookupByName ("doesnotexist")
[...]
libvirt.libvirtError: virDomainLookupByName() failed
then I deliberately kill the remote daemon:
>>> d = conn.lookupByName ("doesnotexist")
libvir: Remote error : Error in the push function.
[...]
The first exception is a Not found condition (not an error) whereas the
second is an error.
Problem (2) is that virterror is over anxious to print error messages to
stderr, even if the caller can handle them and even if (as in the Not
found case) they don't indicate errors. In practical terms this means
that the virt-install loop attached below may print out 1 or 2 error
messages even when it is functioning normally. You'll see an error like
this appearing [sic]:
libvir: Xen Daemon error : GET operation failed:
Since it's difficult to change the LookupBy* functions without changing
the ABI, I suspect that the best thing to do is going to be to add a new
call with better semantics. Therefore I suggest:
virDomainPtr *
virDomainLookup (virConnectPtr conn, int flags,
int id, char *str, int *error);
where flags is one of:
VIR_LOOKUP_BY_ID, VIR_LOOKUP_BY_NAME, VIR_LOOKUP_BY_UUID
or VIR_LOOKUP_BY_UUID_STRING
The return values are:
ret = domain, *error = 0 => found it
ret = NULL, *error = 0 => not found
ret = NULL, *error = 1 => error (check virterror)
Addition 1: There would be a similar function virNetworkLookup, but
without needing the 'id' parameter because networks don't have IDs.
Addition 2: Change the driver internals so that they don't call
virterror in the not found case. (This requires quite a bit of
rejigging in xend_internal, but is not too hard).
Addition 3: Language bindings could be modified to detect this function
and if present change their existing LookupBy* functions to use the new
interface.
Thoughts?
Rich.
----------------------------------------------------
This is the troublesome loop:
logging.debug("Created guest, looking to see if it is running")
# sleep in .25 second increments until either a) we find
# our domain or b) it's been 5 seconds. this is so that
# we can try to gracefully handle domain creation failures
num = 0
d = None
while num < (5 / .25): # 5 seconds, .25 second sleeps
try:
d = self.conn.lookupByName(self.name)
break
except libvirt.libvirtError, e:
logging.debug("No guest running yet " + str(e))
pass
num += 1
time.sleep(0.25)
--
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
17 years, 6 months
[Libvir] PATCH 0/20: Re-factor libvirtd / QEMU driver
by Daniel P. Berrange
The work to refactor the QEMU driver to use the regular libvirt driver API
is now complete. The next 20 (!) patches provide fairly fine-grained steps
refactoring the code. Aside from that which adds an event loop, and the
very last one, they should all be pretty much straightforward refactoring
with no functional change.
With this patch series fully applied there is now only a single daemon
which can serve both remote & QEMU drivers in one go, with no deadlock
issues.
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 -=|
17 years, 6 months
[Libvir] libvirt 0.1.8 Help
by Omer Khalid
Hi,
I have the following code working on libvirt 0.1.9:
########################################
conn = libvirt.openReadOnly(None)
if conn == None:
print 'Failed to open connection to the hypervisor'
#sys.exit(1)
try:
domains = conn.listDomainsID()
num = conn.numOfDomains()
except:
print 'Failed to find the list of domains'
for i in range(num):
try:
dom0 = conn.lookupByID(domains[i])
domInfo = dom0.info()
except:
print "Unexpected error:", sys.exc_info()
##############################################
For legacy reason, I have to get it working on libvirt 0.1.8 but I am
constantly getting the following error:
Unexpected error: (<class libvirt.libvirtError at 0xb7f49f2c>, <
libvirt.libvirtError instance at 0xb7f4f2cc>, <traceback object at
0xb7f44c5c>)
Any help would be much appreciated!
Cheers
Omer
--
----------------------------------------------------------
CERN – European Organization for Nuclear
Research, IT Department, CH-1211
Geneva 23, Switzerland
Phone: +41 (0) 22 767 2224
Fax: +41 (0) 22 766 8683
E-mail : Omer.Khalid(a)cern.ch
Homepage: http://cern.ch/Omer.Khalid
17 years, 6 months
[Libvir] [PATCH] Move common buffer code to lib/ directory
by Richard W.M. Jones
I haven't quite got to my goal of removing _GNU_SOURCE (yet), but this
patch along the way creates a lib/ subdirectory and moves the common
buffer code (from qemud/buf.[ch] and in src/xml.[ch]) there.
There are many, many places which call the buffer functions without
checking the return value. I have manually verified / fixed up the
calls which do bother to check return values, but not added any more
checks where they don't.
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
17 years, 6 months
[Libvir] [PATCH] Add virConnectGetHostname and virConnectGetURI calls, virsh commands, and some related fixes
by Richard W.M. Jones
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
17 years, 6 months
[Libvir] [PATCH] Add virDomainGetConnect and virNetworkGetConnect
by Richard W.M. Jones
As described in this thread:
https://www.redhat.com/archives/libvir-list/2007-June/thread.html#00352
* These functions don't change the reference count for virConnectPtr.
It's be a pain in the neck for callers otherwise.
* I haven't changed the Python bindings, because I'm not confident
enough that I can do that correctly and keep it backwards compatible for
all callers (and anyway what would happen if newer Python bindings were
used together with an older libvirt?). However I did add a comment to
the generator noting that this could be changed in future.
* I tested this with the OCaml bindings with no apparent ill-effects.
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
17 years, 6 months
[Libvir] Useful additional functions for libvirt
by Richard W.M. Jones
[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
17 years, 6 months
[Libvir] [PATCH] Allow maxnames to be 0 in List{, Defined}{Domains, Networks}
by Richard W.M. Jones
It seems a bit pathological to check if maxNames <= 0 and throw an error
if it is 0. In particular if you don't have any defined domains or
networks (both fairly common scenarios) then this causes an error when
you just pass the result of NumOfNetworks straight into ListNetworks.
Backend drivers & QEMU seem to have no problem with maxNames being zero,
so let's allow it.
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
17 years, 6 months
