Re: [libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen
On Wed, Aug 20, 2008 at 07:24:59PM +0100, Daniel P. Berrange wrote: On Wed, Aug 20, 2008 at 02:22:58PM +0100, Richard W.M. Jones wrote: On Tue, Aug 19, 2008 at 11:35:18AM +0100, Daniel P. Berrange wrote: The guarenteed correct solution is actually rather simple - Always report errors against the virConnect object, even in the driver open method - In the cleanup patch of do_open() in libvirt.c, if no global error is set, copy the error from the virConnect object's virError, into the global virError. +1 , although unfortunately this isn't thread-safe. Nothing can be thread-safe unless we change the API. Well we're not making it any less thread-safe. You alrady have to use the virGetLastError() global func - we're simply making sure it actually records all errors. To make it thread-safe we'll need to add a real virGetThreadLastError() API, which is something on my todo list - with that new apps can just call thevirGetThreadLastError() exclusively and never need to know the distinction between global/connection errors which causes so much trouble. I'm fairly sure I can preseve existing semantics at same time with some suitable internal cleverness. I really wished we could avoid thread local storage mess, and in general anything having to do with API exported global variables. In general (I mean for the vast majority of the userland code dealing with libvirt) there is always a domain or connection object where we can plug the error, and provide it in-context. The only exception is the connection creation, maybe this means we need to provide a better entry point for this, but I would really prefer to not expose the notion of thread at the API level. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirt Xen daemon interaction in Red Hat Enterprise with virtualization
On Wed, Aug 20, 2008 at 03:34:38PM -0700, vaibhav chugh wrote: What I am looking for is the exact function call that is made by libvirt to connect to xen daemon. i.e. the function that makes libvirt send out xml RPC message for xend to read. see src/xend_internal.[ch] code in the source of libvirt. session.login_with_password() is not supported by xenAPI version being used in Red Hat. Please help me with the substitute of this method in Red Hat. Very simple, you have the source, take a debugger and see how libvirt connects. If you don't want to spend the effort, use libvirt directly, it was designed explicitely for people like you to not have to mess with the internals of Xen, it's complex, it's hard, sometimes inefficient, and tend to changes between release. The code available from libvirt is the best we have to offer, read it, learn it, and use it ! And please don't post the same request many time, you will get less help if you try to proceed that way. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen
Daniel P. Berrange [EMAIL PROTECTED] wrote: The virConnectOpen method is unfortuantely rather special. While there is a virConnect object available, the current rule is that drivers must report errors against the global error object, because upon failure no virConnect object will be returned to the caller. Unforatunately, despite frequent cleanups of code getting this wrong, I've just audited the remote driver and found another 20 or so places where its wrong. This is clearly not a sustainable approach to error reporting. The guarenteed correct solution is actually rather simple - Always report errors against the virConnect object, even in the driver open method - In the cleanup patch of do_open() in libvirt.c, if no global error is set, copy the error from the virConnect object's virError, into the global virError. With this in place we can change all the drivers back to always report against the error object, and thus cleanup some disgusting code like __virRaiseError (in_open ? NULL : conn, ... To just __virRaiseError (conn, ... Looks good, indeed. ACK Index: src/libvirt.c === ... +/* If not global error was set, copy any error set s/not/no/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: qemud/.libs/libvirtd?
On Thu, Aug 21, 2008 at 12:43:54PM +0900, Jun Koi wrote: OK, but now running /usr/sbin/libvirtd fails ( ... failed to connect to the hypervisor), meanwhile qemud/libvirtd works for me. What should I do now to run libvirtd??? It's not possible to say, given the paucity of information available to us. Try the usual things: look for error messages in log files, 'strace' the processes, run with --verbose option, etc. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] pthread_sigmask undefined reference error
On Thu, Aug 21, 2008 at 02:36:33PM +0900, Jun Koi wrote: Hi, The latest cvs version has an error when compiling: -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables-o virsh virsh-console.o virsh-util-lib.o virsh-virsh.o -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables libvirt.la ../gnulib/lib/libgnu.la gcc -g -O2 -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -o .libs/virsh virsh-console.o virsh-util-lib.o virsh-virsh.o -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables ./.libs/libvirt.so ../gnulib/lib/.libs/libgnu.a ./.libs/libvirt.so: undefined reference to `pthread_sigmask' collect2: ld returned 1 exit status make[3]: *** [virsh] Error 1 make[3]: Leaving directory `/home/jun/projects/libvirt-0821/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/jun/projects/libvirt-0821/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jun/projects/libvirt-0821' make: *** [all] Error 2 It seems I lack a particular library?? That symbol is in libpthread.so which we should already be linking against because we already use many pthread symbols. Can you provide the output of $ ldd src/.libs/libvirt.so.0 And what OS distribution, version and CPU architecture are you using ? Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen
On Thu, Aug 21, 2008 at 08:35:25AM +0200, Daniel Veillard wrote: On Wed, Aug 20, 2008 at 07:24:59PM +0100, Daniel P. Berrange wrote: On Wed, Aug 20, 2008 at 02:22:58PM +0100, Richard W.M. Jones wrote: On Tue, Aug 19, 2008 at 11:35:18AM +0100, Daniel P. Berrange wrote: The guarenteed correct solution is actually rather simple - Always report errors against the virConnect object, even in the driver open method - In the cleanup patch of do_open() in libvirt.c, if no global error is set, copy the error from the virConnect object's virError, into the global virError. +1 , although unfortunately this isn't thread-safe. Nothing can be thread-safe unless we change the API. Well we're not making it any less thread-safe. You alrady have to use the virGetLastError() global func - we're simply making sure it actually records all errors. To make it thread-safe we'll need to add a real virGetThreadLastError() API, which is something on my todo list - with that new apps can just call thevirGetThreadLastError() exclusively and never need to know the distinction between global/connection errors which causes so much trouble. I'm fairly sure I can preseve existing semantics at same time with some suitable internal cleverness. I really wished we could avoid thread local storage mess, and in general anything having to do with API exported global variables. In general (I mean for the vast majority of the userland code dealing with libvirt) there is always a domain or connection object where we can plug the error, and provide it in-context. The only exception is the connection creation, maybe this means we need to provide a better entry point for this, but I would really prefer to not expose the notion of thread at the API level. Well you see I want to be able to use the same virConnectPtr object from multiple threads. I've looked at how todo this and it actually won't be very hard once we have a way to report thread-local errors. Re-using a single virConnectPtr object is important because when talking to a remote libvirtd instance, you don't want to have to open multiple connections for each thread in your app, because that will require the user to re-authenticate multiple times (or for the app to store your credentials - not cool) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen
On Thu, Aug 21, 2008 at 09:41:12AM +0100, Daniel P. Berrange wrote: On Thu, Aug 21, 2008 at 08:35:25AM +0200, Daniel Veillard wrote: To make it thread-safe we'll need to add a real virGetThreadLastError() API, which is something on my todo list - with that new apps can just call thevirGetThreadLastError() exclusively and never need to know the distinction between global/connection errors which causes so much trouble. I'm fairly sure I can preseve existing semantics at same time with some suitable internal cleverness. I really wished we could avoid thread local storage mess, and in general anything having to do with API exported global variables. In general (I mean for the vast majority of the userland code dealing with libvirt) there is always a domain or connection object where we can plug the error, and provide it in-context. The only exception is the connection creation, maybe this means we need to provide a better entry point for this, but I would really prefer to not expose the notion of thread at the API level. Well you see I want to be able to use the same virConnectPtr object from multiple threads. I've looked at how todo this and it actually won't be very hard once we have a way to report thread-local errors. not very hard ??? You expect to put a global lock in the connection The threading problem is a pandora box, once you provide the functionality people will use it in ways you didn't expect. You will see things like people closing the connection in one thread while another thread is still using it. I don't think you can catch all scenarios so i'm quite worried about suggesting it will be usable and then facing undebuggable scenarios coming from lost users. Re-using a single virConnectPtr object is important because when talking to a remote libvirtd instance, you don't want to have to open multiple connections for each thread in your app, because that will require the user to re-authenticate multiple times (or for the app to store your credentials - not cool) you keep one thread per connection. You will have to lock anyway, it's not like you will gain anything by trying to parallelize on a single connection. I really don't see what you're trying to do. Even entry points without side effect will need some kind of locking. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Add libvirt_lxc to specfile
FYI, just committed this change to fix the broken build last night
Daniel
Index: libvirt.spec.in
===
RCS file: /data/cvs/libvirt/libvirt.spec.in,v
retrieving revision 1.90
diff -u -p -r1.90 libvirt.spec.in
--- libvirt.spec.in 20 Aug 2008 13:16:29 - 1.90
+++ libvirt.spec.in 21 Aug 2008 08:50:24 -
@@ -3,6 +3,8 @@
%define with_xen 1
%define with_xen_proxy 1
%define with_qemu 1
+%define with_openvz1
+%define with_lxc 1
%define with_polkit0
# Xen is available only on i386 x86_64 ia64
@@ -152,8 +154,18 @@ of recent versions of Linux (and other O
%define _without_qemu --without-qemu
%endif
+%if ! %{with_openvz}
+%define _without_openvz --without-openvz
+%endif
+
+%if ! %{with_lxc}
+%define _without_lxc --without-lxc
+%endif
+
%configure %{?_without_xen} \
%{?_without_qemu} \
+ %{?_without_openvz} \
+ %{?_without_lxc} \
--with-init-script=redhat \
--with-qemud-pid-file=%{_localstatedir}/run/libvirt_qemud.pid \
--with-remote-file=%{_localstatedir}/run/libvirtd.pid
@@ -248,6 +260,9 @@ fi
%attr(4755, root, root) %{_libexecdir}/libvirt_proxy
%endif
%attr(0755, root, root) %{_libexecdir}/libvirt_parthelper
+%if %{with_openvz}
+%attr(0755, root, root) %{_libexecdir}/libvirt_lxc
+%endif
%attr(0755, root, root) %{_sbindir}/libvirtd
%doc docs/*.rng
%doc docs/*.xml
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen
On Thu, Aug 21, 2008 at 11:30:11AM +0200, Daniel Veillard wrote: On Thu, Aug 21, 2008 at 09:41:12AM +0100, Daniel P. Berrange wrote: On Thu, Aug 21, 2008 at 08:35:25AM +0200, Daniel Veillard wrote: To make it thread-safe we'll need to add a real virGetThreadLastError() API, which is something on my todo list - with that new apps can just call thevirGetThreadLastError() exclusively and never need to know the distinction between global/connection errors which causes so much trouble. I'm fairly sure I can preseve existing semantics at same time with some suitable internal cleverness. I really wished we could avoid thread local storage mess, and in general anything having to do with API exported global variables. In general (I mean for the vast majority of the userland code dealing with libvirt) there is always a domain or connection object where we can plug the error, and provide it in-context. The only exception is the connection creation, maybe this means we need to provide a better entry point for this, but I would really prefer to not expose the notion of thread at the API level. Well you see I want to be able to use the same virConnectPtr object from multiple threads. I've looked at how todo this and it actually won't be very hard once we have a way to report thread-local errors. not very hard ??? You expect to put a global lock in the connection The threading problem is a pandora box, once you provide the functionality people will use it in ways you didn't expect. You will see things like people closing the connection in one thread while another thread is still using it. I don't think you can catch all scenarios so i'm quite worried about suggesting it will be usable and then facing undebuggable scenarios coming from lost users. Well, ok so let me step back a bit because there's actually several layers to this issue... - The libvirtd is single threaded. This was reasonable at first, but some of our APIs take a long time to complete, so we need to have libvirtd parallelized. - The QEMU/LXC drivers have state stored in the daemon, so even if you merely allow libvirtd to parallelize by putting long running connections in the 'background' you ned to have locking in the QEMU/LXC drivers. - Given that we need to have locking anyway, might as well just make the libvirtd daemon properly multi-threaded, rather than trying to have a multi-request queuing system. - Once you've done all that, then solving the virError thread-local issue is all that remains to allow virConnect to be accessed by multiple threads We need to do 1-3 in order to make libvirtd more scalable. At which point 4 becomes 'not very hard' :-) That said, there is one other option I've thought about instead of doing step 4, we could add a 'virConnectDup' method. This would take an existing connection object, and create an independant copy of it that another thread could use. The key would be that the internal driver would automagically pass authentication credentials somehow, so you wouldn't have to re-authenticate the 2nd connection. For the remote driver, this could be as simple as invoking an RPC call to fetch a one-time key, and passing that to the 2nd connection to use as their authentication credential. Re-using a single virConnectPtr object is important because when talking to a remote libvirtd instance, you don't want to have to open multiple connections for each thread in your app, because that will require the user to re-authenticate multiple times (or for the app to store your credentials - not cool) you keep one thread per connection. You will have to lock anyway, it's not like you will gain anything by trying to parallelize on a single connection. I really don't see what you're trying to do. Even entry points without side effect will need some kind of locking. The libvirt APIs are in fact very parallelizable. There are very few times you need to access state on the virConnectPtr object - most of the time we're dealing with virDomainPtr objects. So you merely need to lock the connection, while you obtain a lock on the virDomainPtr object, then you can release the connection lock. So the connection lock is held for virtually no time at all. I reckon it'll parallelize very well. But its probably not worth getting into this debate unless I've actually got some proof of concept code to show, which is probably quite a long way out timewise... Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Ensure errors are guarenteed reported in virConnectOpen
On Thu, Aug 21, 2008 at 10:42:51AM +0100, Daniel P. Berrange wrote: Well, ok so let me step back a bit because there's actually several layers to this issue... - The libvirtd is single threaded. This was reasonable at first, but some of our APIs take a long time to complete, so we need to have libvirtd parallelized. - The QEMU/LXC drivers have state stored in the daemon, so even if you merely allow libvirtd to parallelize by putting long running connections in the 'background' you ned to have locking in the QEMU/LXC drivers. - Given that we need to have locking anyway, might as well just make the libvirtd daemon properly multi-threaded, rather than trying to have a multi-request queuing system. - Once you've done all that, then solving the virError thread-local issue is all that remains to allow virConnect to be accessed by multiple threads We need to do 1-3 in order to make libvirtd more scalable. At which point 4 becomes 'not very hard' :-) That said, there is one other option I've thought about instead of doing step 4, we could add a 'virConnectDup' method. This would take an existing connection object, and create an independant copy of it that another thread could use. The key would be that the internal driver would automagically pass authentication credentials somehow, so you wouldn't have to re-authenticate the 2nd connection. For the remote driver, this could be as simple as invoking an RPC call to fetch a one-time key, and passing that to the 2nd connection to use as their authentication credential. Actually the one-time key idea wouldn't work because that wouldn't let us negotiate the session encryption, which is done by SASL at the time we authenticate the client. Rich suggested perhaps sharing a single TCP connection and multiplexing messages on it - we have a serial number with every message/reply so this is doable in theory. It'd require some fun code to hand-off replies between the virConnect objects sharing the connection, but might be more viable in general. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Improve python exception messages
On Tue, Aug 19, 2008 at 10:31:34AM +0100, Daniel P. Berrange wrote:
Most of the libvirt python API bindings use code snippet like this when
raising an exception:
if ret is None:raise libvirtError('virConnectOpen() failed')
THis sets the message associated with the exception to
virConnectOpen() failed
This contains essentially zero useful information - you can see that it
was virConnectOpen which failed from the stack trace.
Now the libvirt error object has a real message, such as
authentication failed
Or
unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused
This patch makes sure we extract this real error message and use it to
set the message associated with the exception object. This is one step
in getting better error reporting for virt-install/virt-manager, which
is particularly needed for remote connections
This patch was flawed - it missed out the error message info when passed
in a domain/network/volume/pool instead of a connection object. Here is
an updated patch which addresses that
Daniel
Index: python/libvir.py
===
RCS file: /data/cvs/libvirt/python/libvir.py,v
retrieving revision 1.9
diff -u -r1.9 libvir.py
--- python/libvir.py11 Jun 2008 07:49:01 - 1.9
+++ python/libvir.py21 Aug 2008 10:58:53 -
@@ -15,8 +15,7 @@
# The root of all libvirt errors.
class libvirtError(Exception):
-def __init__(self, msg, conn=None, dom=None, net=None, pool=None,
vol=None):
-Exception.__init__(self, msg)
+def __init__(self, defmsg, conn=None, dom=None, net=None, pool=None,
vol=None):
if dom is not None:
conn = dom._conn
@@ -28,9 +27,17 @@
conn = vol._conn
if conn is None:
-self.err = virGetLastError()
+err = virGetLastError()
+else:
+err = conn.virConnGetLastError()
+if err is None:
+msg = defmsg
else:
-self.err = conn.virConnGetLastError()
+msg = err[2]
+
+Exception.__init__(self, msg)
+
+self.err = err
def get_error_code(self):
if self.err is None:
@@ -77,12 +84,6 @@
return None
return self.err[8]
-def __str__(self):
-if self.get_error_message() is None:
-return Exception.__str__(self)
-else:
-return Exception.__str__(self) + + self.get_error_message()
-
#
# register the libvirt global error handler
#
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] pthread_sigmask undefined reference error
On Thu, Aug 21, 2008 at 5:34 PM, Daniel P. Berrange [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 02:36:33PM +0900, Jun Koi wrote: Hi, The latest cvs version has an error when compiling: -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables-o virsh virsh-console.o virsh-util-lib.o virsh-virsh.o -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables libvirt.la ../gnulib/lib/libgnu.la gcc -g -O2 -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -o .libs/virsh virsh-console.o virsh-util-lib.o virsh-virsh.o -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables ./.libs/libvirt.so ../gnulib/lib/.libs/libgnu.a ./.libs/libvirt.so: undefined reference to `pthread_sigmask' collect2: ld returned 1 exit status make[3]: *** [virsh] Error 1 make[3]: Leaving directory `/home/jun/projects/libvirt-0821/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/jun/projects/libvirt-0821/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jun/projects/libvirt-0821' make: *** [all] Error 2 It seems I lack a particular library?? That symbol is in libpthread.so which we should already be linking against because we already use many pthread symbols. Can you provide the output of $ ldd src/.libs/libvirt.so.0 # ldd src/.libs/libvirt.so.0 linux-gate.so.1 = (0xb7f4b000) libxml2.so.2 = /usr/lib/libxml2.so.2 (0xb7da) libgnutls.so.13 = /usr/lib/libgnutls.so.13 (0xb7d2a000) libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0xb7d12000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7bc3000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb7bbf000) libz.so.1 = /usr/lib/libz.so.1 (0xb7baa000) libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0xb7b85000) libtasn1.so.3 = /usr/lib/libtasn1.so.3 (0xb7b75000) libgcrypt.so.11 = /lib/libgcrypt.so.11 (0xb7b27000) libresolv.so.2 = /lib/tls/i686/cmov/libresolv.so.2 (0xb7b14000) /lib/ld-linux.so.2 (0xb7f4c000) libgpg-error.so.0 = /lib/libgpg-error.so.0 (0xb7b1) And what OS distribution, version and CPU architecture are you using ? It is Ubuntu 8.04, on x86. Do you have any idea? Thanks, Jun -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Improve python exception messages
On Thu, Aug 21, 2008 at 12:00:46PM +0100, Daniel P. Berrange wrote: On Tue, Aug 19, 2008 at 10:31:34AM +0100, Daniel P. Berrange wrote: This patch makes sure we extract this real error message and use it to set the message associated with the exception object. This is one step in getting better error reporting for virt-install/virt-manager, which is particularly needed for remote connections This patch was flawed - it missed out the error message info when passed in a domain/network/volume/pool instead of a connection object. Here is an updated patch which addresses that okay, +1, hopefully that time my mail will make up to the list, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Bug: Libvirt java : Connect domainDefineXML shows no effect, listDefinedDomains throws exception
Hi everybody in the libvirt java binding the the Connect method domainDefineXML() seems to have no effect. Implementing a full lifecycle junit test for the virtual machine this method does not have any result. Perhaps related: listDefinedDomains shows empty result If at least one domain is running, listDomains show correctly the virtual machine. Anybody going to fix this? Cheers, Thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Allow specific FDs to be kept open in virExec()
With my recent patches to virExec(), all FDs except stdin/out/err are closed
before the child is exec'd to prevent accidental leaks. Of course I forgot
the one key place where we need to propagate FDs... The TAP devices passed
to QEMU.
This patch adds a 'keepfd' parameter to virExec() which allows the caller
to specify a bitset of file descriptors to keep open, and updates the
callers to use this as required. The QEMU driver specifies any TAP fds
and the LXC driver specifies its PTY this way removing a previous hack.
QEMU networking works again with fix
lxc_driver.c | 17 ++---
openvz_driver.c |6 --
qemu_driver.c | 26 +++---
storage_backend.c |6 --
util.c|8 ++--
util.h|7 +++
6 files changed, 54 insertions(+), 16 deletions(-)
Daniel
Index: src/lxc_driver.c
===
RCS file: /data/cvs/libvirt/src/lxc_driver.c,v
retrieving revision 1.23
diff -u -p -r1.23 lxc_driver.c
--- src/lxc_driver.c20 Aug 2008 20:55:32 - 1.23
+++ src/lxc_driver.c21 Aug 2008 13:52:25 -
@@ -615,6 +615,8 @@ static int lxcControllerStart(virConnect
const char **largv = NULL;
pid_t child;
int status;
+char *keepfd = NULL;
+char appPtyStr[30];
#define ADD_ARG_SPACE \
do { \
@@ -638,11 +640,13 @@ static int lxcControllerStart(virConnect
goto no_memory; \
} while (0)
+snprintf(appPtyStr, sizeof(appPtyStr), %d, appPty);
+
ADD_ARG_LIT(vm-def-emulator);
ADD_ARG_LIT(--name);
ADD_ARG_LIT(vm-def-name);
ADD_ARG_LIT(--console);
-ADD_ARG_LIT(0); /* Passing console master PTY as FD 0 */
+ADD_ARG_LIT(appPtyStr);
ADD_ARG_LIT(--background);
for (i = 0 ; i nveths ; i++) {
@@ -652,10 +656,15 @@ static int lxcControllerStart(virConnect
ADD_ARG(NULL);
-vm-stdin_fd = appPty; /* Passing console master PTY as FD 0 */
+vm-stdin_fd = -1;
vm-stdout_fd = vm-stderr_fd = logfd;
-if (virExec(conn, largv, NULL, child,
+if (VIR_ALLOC_N(keepfd, VIR_EXEC_FDSET_SIZE()) 0)
+goto no_memory;
+
+VIR_EXEC_FDSET_ON(keepfd, appPty);
+
+if (virExec(conn, largv, NULL, keepfd, child,
vm-stdin_fd, vm-stdout_fd, vm-stderr_fd,
VIR_EXEC_NONE) 0)
goto cleanup;
@@ -686,6 +695,8 @@ static int lxcControllerStart(virConnect
ret = 0;
cleanup:
+VIR_FREE(keepfd);
+
for (i = 0 ; i largc ; i++)
VIR_FREE(largv[i]);
Index: src/openvz_driver.c
===
RCS file: /data/cvs/libvirt/src/openvz_driver.c,v
retrieving revision 1.43
diff -u -p -r1.43 openvz_driver.c
--- src/openvz_driver.c 20 Aug 2008 20:48:36 - 1.43
+++ src/openvz_driver.c 21 Aug 2008 13:52:25 -
@@ -807,7 +807,8 @@ static int openvzListDomains(virConnectP
char *endptr;
const char *cmd[] = {VZLIST, -ovpsid, -H , NULL};
-ret = virExec(conn, cmd, NULL, pid, -1, outfd, errfd, VIR_EXEC_NONE);
+ret = virExec(conn, cmd, NULL, NULL,
+ pid, -1, outfd, errfd, VIR_EXEC_NONE);
if(ret == -1) {
openvzError(conn, VIR_ERR_INTERNAL_ERROR,
_(Could not exec %s), VZLIST);
@@ -844,7 +845,8 @@ static int openvzListDefinedDomains(virC
const char *cmd[] = {VZLIST, -ovpsid, -H, -S, NULL};
/* the -S options lists only stopped domains */
-ret = virExec(conn, cmd, NULL, pid, -1, outfd, errfd, VIR_EXEC_NONE);
+ret = virExec(conn, cmd, NULL, NULL,
+ pid, -1, outfd, errfd, VIR_EXEC_NONE);
if(ret == -1) {
openvzError(conn, VIR_ERR_INTERNAL_ERROR,
_(Could not exec %s), VZLIST);
Index: src/qemu_driver.c
===
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.111
diff -u -p -r1.111 qemu_driver.c
--- src/qemu_driver.c 20 Aug 2008 20:48:36 - 1.111
+++ src/qemu_driver.c 21 Aug 2008 13:52:26 -
@@ -847,6 +847,7 @@ static int qemudStartVMDaemon(virConnect
int *tapfds = NULL;
int ntapfds = 0;
int qemuCmdFlags;
+char *keepfd = NULL;
if (virDomainIsActive(vm)) {
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
@@ -950,12 +951,22 @@ static int qemudStartVMDaemon(virConnect
vm-stdout_fd = -1;
vm-stderr_fd = -1;
-ret = virExec(conn, argv, NULL, vm-pid,
- vm-stdin_fd, vm-stdout_fd, vm-stderr_fd,
- VIR_EXEC_NONBLOCK);
-if (ret == 0) {
-vm-def-id = driver-nextvmid++;
-vm-state = migrateFrom ? VIR_DOMAIN_PAUSED : VIR_DOMAIN_RUNNING;
+if (VIR_ALLOC_N(keepfd, VIR_EXEC_FDSET_SIZE()) 0) {
+ret = -1;
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
Re: [libvirt] Bug: Libvirt java : Connect domainDefineXML shows no effect, listDefinedDomains throws exception
On Thu, Aug 21, 2008 at 02:51:44PM +0200, Thomas Fricke wrote: Hi everybody in the libvirt java binding the the Connect method domainDefineXML() seems to have no effect. Implementing a full lifecycle junit test for the virtual machine this method does not have any result. Perhaps related: listDefinedDomains shows empty result If at least one domain is running, listDomains show correctly the virtual machine. Anybody going to fix this? Okay, what platform, what hypervisor (xen ?) and a bit of java code reproducing the error will help me trying to fix this. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] introducing source name (for logical storage pools)
Oops - that was against an old base. Sorry. Here's the new one.
Also fixed a few other issues ...
Dave
On Mon, 2008-08-18 at 12:12 -0400, David Lively wrote:
Same patch, resubmitted after fixing allocation issue you pointed out.
Looking more closely, I notice it was leaking when pool/source/name was
specified. Just added a strdup for the other case (when
pool/source/name defaults to pool/name) and a VIR_FREE in the
destructor.
Dave
On Tue, 2008-08-12 at 05:21 -0400, Daniel Veillard wrote:
On Fri, Aug 08, 2008 at 03:17:52PM -0400, David Lively wrote:
Hi Folks -
This small patch is a proposed prerequisite for the storage pool
discovery patch I submitted last week.
Daniel B proposed having storage pool discovery return a bunch of XML
storage source elements, rather than full pool elements (which
contain target-dependent details like the local pool name and device
or mount path -- things which don't need to be decided unless/until the
pool is defined).
I like his suggestion a lot, and I think it addresses the final
API-definition problem keeping storage pool discovery out of libvirt.
But ... it doesn't quite work for logical storage pools because those
are created from the pool name element (which is the same as the
volume group name).
I will let Daniel B comment on the pure storage aspects of the patch.
The patch looks fine to me except for one thing:
[...]
+if (options-flags VIR_STORAGE_BACKEND_POOL_SOURCE_NAME) {
+ret-source.name = virXPathString(conn,
string(/pool/source/name), ctxt);
+if (ret-source.name == NULL) {
+/* source name defaults to pool name */
+ret-source.name = ret-name;
+}
+}
I'm vary of allocation issues there.
Basically the patch adds a new string field to the record. But I could not
see
any deallocation addition in the patch, and the field seems to only be
set by copying another value. Maybe this is fine now, but if we ever update
the field in a different way (which I would expect at some point in the
code
evolution) then we will have a leak.
So instead of copying the string pointer directly, I suggest to do a
string
dup and in the freeing part of the record , do the VIR_FREE call for it.
Otherwise this looks fine to me
Daniel
This patch introduces a new source element name, which is distinct
from the pool name. name is used only by the logical storage
backend, and represents the volume group name. For convenience and
back-compatibility, source name defaults to the pool name if not
specified when the pool is defined, and pool name defaults to the
source name if not specified. There is no requirement that pool and
source name be the same, though.
Signed-off-by: David Lively [EMAIL PROTECTED]
diff --git a/src/storage_backend.h b/src/storage_backend.h
index 797ca01..422f26c 100644
--- a/src/storage_backend.h
+++ b/src/storage_backend.h
@@ -53,6 +53,7 @@ enum {
VIR_STORAGE_BACKEND_POOL_SOURCE_DEVICE = (11),
VIR_STORAGE_BACKEND_POOL_SOURCE_DIR = (12),
VIR_STORAGE_BACKEND_POOL_SOURCE_ADAPTER = (13),
+VIR_STORAGE_BACKEND_POOL_SOURCE_NAME= (14),
};
typedef struct _virStorageBackendPoolOptions virStorageBackendPoolOptions;
diff --git a/src/storage_backend_logical.c b/src/storage_backend_logical.c
index 0c4f6a5..382078b 100644
--- a/src/storage_backend_logical.c
+++ b/src/storage_backend_logical.c
@@ -80,7 +80,7 @@ virStorageBackendLogicalSetActive(virConnectPtr conn,
cmdargv[0] = VGCHANGE;
cmdargv[1] = on ? -ay : -an;
-cmdargv[2] = pool-def-name;
+cmdargv[2] = pool-def-source.name;
cmdargv[3] = NULL;
if (virRun(conn, cmdargv, NULL) 0)
@@ -213,7 +213,7 @@ virStorageBackendLogicalFindLVs(virConnectPtr conn,
LVS, --separator, :, --noheadings, --units, b,
--unbuffered, --nosuffix, --options,
lv_name,uuid,devices,seg_size,vg_extent_size,
-pool-def-name, NULL
+pool-def-source.name, NULL
};
int exitstatus;
@@ -288,7 +288,7 @@ virStorageBackendLogicalBuildPool(virConnectPtr conn,
}
vgargv[n++] = VGCREATE;
-vgargv[n++] = pool-def-name;
+vgargv[n++] = pool-def-source.name;
pvargv[0] = PVCREATE;
pvargv[2] = NULL;
@@ -365,7 +365,7 @@ virStorageBackendLogicalRefreshPool(virConnectPtr conn,
const char *prog[] = {
VGS, --separator, :, --noheadings, --units, b, --unbuffered,
--nosuffix, --options, vg_size,vg_free,
-pool-def-name, NULL
+pool-def-source.name, NULL
};
int exitstatus;
@@ -419,7 +419,7 @@ virStorageBackendLogicalDeletePool(virConnectPtr conn,
unsigned int flags ATTRIBUTE_UNUSED)
{
const char *cmdargv[] = {
-VGREMOVE, -f, pool-def-name, NULL
+VGREMOVE, -f, pool-def-source.name, NULL
};
if (virRun(conn,
[libvirt] [PATCH] storage pool discovery
Hi Folks -
Here's my second pass at storage pool discovery. I've taken Daniel's
suggestion and made it return a single XML doc containing source
elements rather than an array of pool docs (and also incorporated
suggestions from Daniel V and Jim M).
Note that the storage source name patch is closely related
(without it, the source docs returned for logical pools aren't
correct).
Dave
diff --git a/configure.in b/configure.in
index 0513a72..f29a0fa 100644
--- a/configure.in
+++ b/configure.in
@@ -660,6 +660,11 @@ if test $with_storage_fs = yes -o $with_storage_fs = check; then
fi
fi
AM_CONDITIONAL([WITH_STORAGE_FS], [test $with_storage_fs = yes])
+if test $with_storage_fs = yes; then
+ AC_PATH_PROG([SHOWMOUNT], [showmount], [], [$PATH:/sbin:/usr/sbin])
+ AC_DEFINE_UNQUOTED([SHOWMOUNT], [$SHOWMOUNT],
+[Location or name of the showmount program])
+fi
AC_PATH_PROG([QEMU_IMG], [qemu-img], [], [$PATH:/sbin:/usr/sbin:/bin:/usr/bin])
if test -n $QEMU_IMG ; then
diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h
index 9c3e1c2..5308fa9 100644
--- a/include/libvirt/libvirt.h
+++ b/include/libvirt/libvirt.h
@@ -890,6 +890,14 @@ int virConnectListDefinedStoragePools(virConnectPtr conn,
int maxnames);
/*
+ * Query a host for storage pools of a particular type
+ */
+char * virConnectDiscoverStoragePools(virConnectPtr conn,
+ const char *type,
+ const char *srcSpec,
+ unsigned int flags);
+
+/*
* Lookup pool by name or uuid
*/
virStoragePoolPtr virStoragePoolLookupByName (virConnectPtr conn,
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index f077a26..3d06d76 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -890,6 +890,14 @@ int virConnectListDefinedStoragePools(virConnectPtr conn,
int maxnames);
/*
+ * Query a host for storage pools of a particular type
+ */
+char * virConnectDiscoverStoragePools(virConnectPtr conn,
+ const char *type,
+ const char *srcSpec,
+ unsigned int flags);
+
+/*
* Lookup pool by name or uuid
*/
virStoragePoolPtr virStoragePoolLookupByName (virConnectPtr conn,
diff --git a/qemud/remote.c b/qemud/remote.c
index b5a6ec9..43b3a56 100644
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -2958,6 +2958,27 @@ remoteDispatchListStoragePools (struct qemud_server *server ATTRIBUTE_UNUSED,
}
static int
+remoteDispatchDiscoverStoragePools (struct qemud_server *server ATTRIBUTE_UNUSED,
+struct qemud_client *client,
+remote_message_header *req,
+remote_discover_storage_pools_args *args,
+remote_discover_storage_pools_ret *ret)
+{
+CHECK_CONN(client);
+
+ret-xml =
+virConnectDiscoverStoragePools (client-conn,
+args-type,
+args-srcSpec ? *args-srcSpec : NULL,
+args-flags);
+if (ret-xml == NULL)
+return -1;
+
+return 0;
+}
+
+
+static int
remoteDispatchStoragePoolCreate (struct qemud_server *server ATTRIBUTE_UNUSED,
struct qemud_client *client,
remote_message_header *req,
diff --git a/qemud/remote_dispatch_localvars.h b/qemud/remote_dispatch_localvars.h
index d889c8a..6915d5a 100644
--- a/qemud/remote_dispatch_localvars.h
+++ b/qemud/remote_dispatch_localvars.h
@@ -137,6 +137,8 @@ remote_domain_attach_device_args lv_remote_domain_attach_device_args;
remote_num_of_networks_ret lv_remote_num_of_networks_ret;
remote_storage_pool_get_info_args lv_remote_storage_pool_get_info_args;
remote_storage_pool_get_info_ret lv_remote_storage_pool_get_info_ret;
+remote_discover_storage_pools_args lv_remote_discover_storage_pools_args;
+remote_discover_storage_pools_ret lv_remote_discover_storage_pools_ret;
remote_list_storage_pools_args lv_remote_list_storage_pools_args;
remote_list_storage_pools_ret lv_remote_list_storage_pools_ret;
remote_domain_restore_args lv_remote_domain_restore_args;
diff --git a/qemud/remote_dispatch_proc_switch.h b/qemud/remote_dispatch_proc_switch.h
index ebb2433..1850b92 100644
--- a/qemud/remote_dispatch_proc_switch.h
+++ b/qemud/remote_dispatch_proc_switch.h
@@ -41,6 +41,15 @@ case REMOTE_PROC_AUTH_SASL_STEP:
case REMOTE_PROC_CLOSE:
fn = (dispatch_fn) remoteDispatchClose;
break;
[libvirt] [PATCH] autobuild.sh: Fix minor shell-quoting bugs.
I noticed some minor quoting problems in ovirt's autobuild.sh, and since part of that code came from here, ... Here's a patch: From 50c37706729b7748dbf92290c6ecf6bc3982f681 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Thu, 21 Aug 2008 17:55:19 +0200 Subject: [PATCH] autobuild.sh: Fix minor shell-quoting bugs. * autobuild.sh: Remove unnecessary quotes. Don't choke on a file name argument containing a space. Don't misbehave for $AUTOBUILD_INSTALL_ROOT containing a shell meta-character. --- autobuild.sh |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/autobuild.sh b/autobuild.sh index ce12692..7ae5d1e 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -5,7 +5,7 @@ set -v # Make things clean. -test -n $1 RESULTS=$1 || RESULTS=results.log +test -n $1 RESULTS=$1 || RESULTS=results.log test -f Makefile make -k distclean || : rm -rf coverage @@ -14,7 +14,7 @@ rm -rf coverage #mkdir build #cd build -./autogen.sh --prefix=$AUTOBUILD_INSTALL_ROOT \ +./autogen.sh --prefix=$AUTOBUILD_INSTALL_ROOT \ --enable-test-coverage \ --enable-compile-warnings=error \ --with-openvz \ @@ -25,8 +25,8 @@ make make install set -o pipefail -make check 21 | tee $RESULTS -make syntax-check 21 | tee -a $RESULTS +make check 21 | tee $RESULTS +make syntax-check 21 | tee -a $RESULTS test -x /usr/bin/lcov make cov rm -f *.tar.gz -- 1.6.0.90.g436ed -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] configure.in: Prepend -lpthread to LIBS if required.
Jun Koi [EMAIL PROTECTED] wrote: The latest cvs version has an error when compiling: make[3]: Entering directory `/home/jun/projects/libvirt-0821/src' /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -Wall ... ./.libs/libvirt.so: undefined reference to `pthread_sigmask' collect2: ld returned 1 exit status make[3]: *** [virsh] Error 1 Thanks for the report. Next time, please tell us about your system, because I didn't 'see any such problem on a rawhide-based build. However, I did reproduce it on a Debian/unstable system. Applying the patch below solved the problem for me. I'll check it in soon. From 3b51f7ad00bc8acde5bddf6cc61517289b9b0c4a Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Thu, 21 Aug 2008 20:17:19 +0200 Subject: [PATCH] configure.in: Prepend -lpthread to LIBS if required. * configure.in: With an empty ACTION_IF_FOUND, AC_CHECK_LIB would have done that for us automatically, but when there is an explicit 3rd argument, those commands are run instead of the default --- configure.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.in b/configure.in index 3789abd..9479f1c 100644 --- a/configure.in +++ b/configure.in @@ -90,6 +90,7 @@ AC_CHECK_HEADER([pthread.h], [AC_CHECK_LIB([pthread],[pthread_join],[ AC_DEFINE([HAVE_LIBPTHREAD],[],[Define if pthread (-lpthread)]) AC_DEFINE([HAVE_PTHREAD_H],[],[Define if pthread.h]) + LIBS=-lpthread $LIBS ])]) dnl Miscellaneous external programs. -- 1.6.0.90.g436ed -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
RE: [libvirt] Using Xen config files
I'm still having problems with this. I've dug around and found errors in
the qemu-dm log.
When I try to start the VM with libvirt, the error I'm getting is:
xs_read(/vm/414e73de-cf1e-487c-87e0-d4ebf7a23576/rtc/timeoffset): read
error
I did a xenstore-ls on the /vm/414e73de-cf1e-487c-87e0-d4ebf7a23576
directory and sure enough, rtc/timeoffset is not there. When I start the VM
with the Xen config file I used to generate the XML the rtc/timeoffset is
there (timeoffset is set to 0).
Is there a way to set that in the XML? I didn't see it in the online XML
description.
I'm using a slightly different XML description than I had originally so I've
included here (along with the Xen Config file)
Thanks!
-matthew
const char* foo =
domain type='xen'
nameLinuxVM/name
uuid414e73de-cf1e-487c-87e0-d4ebf7a23576/uuid
os
typehvm/type
loader/usr/lib/xen/boot/hvmloader/loader
boot dev='hd'/
/os
memory512000/memory
vcpu1/vcpu
on_shutdownshutdown/on_shutdown
on_rebootrestart/on_reboot
on_crashrestart/on_crash
features
pae/
acpi/
apic/
/features
clock sync='localtime'/
devices
emulator/usr/lib/xen/bin/qemu-dm/emulator
disk type='block'
source dev='/dev/vgvms/LinuxVM'/
target dev='hda'/
/disk
interface type='ioemu'
mac address='7A:AB:D0:01:82:98'/
/interface
input type='tablet' bus='usb'/
graphics type='sdl' password=''/
serial type='pty'/
/devices
/domain;
//serial = pty
int main (int argc, char** argv)
{
virConnectPtr con; /* connection to the Xen hypervisor */
virDomainPtr domain;
virInitialize();
con = virConnectOpen (xen:///);
if (!con) {
virErrorPtr err = virGetLastError ();
printf (virConnectOpen failed: %s\n,
err-message);
return -1;
}
domain = virDomainDefineXML (con, foo);
if (!domain) {
virErrorPtr err = virConnGetLastError (con);
printf (virDomainDefineXML failed: %s\n,
err-message);
} else {
if (virDomainCreate (domain) 0) {
virErrorPtr err = virConnGetLastError (con);
printf (virDomainCreate failed: %s\n,
err-message);
} else {
virDomainInfo info = {0};
virDomainGetInfo (domain, info);
printf (state = %d\n, info.state);
getchar ();
}
}
virConnectClose (con);
return 0;
}
# Automatically generated xen config file
name = LinuxVM
builder = hvm
memory = 500
disk = [ 'phy:/dev/vgvms/LinuxVM,hda,w', ]
vif = [ 'type=ioemu, mac=7A:AB:D0:01:82:98', ]
uuid = 414e73de-cf1e-487c-87e0-d4ebf7a23576
device_model = /usr/lib/xen/bin/qemu-dm
kernel = /usr/lib/xen/boot/hvmloader
vnc=1
vnc=0
sdl=1
stdvga=0
boot=cda
usbdevice=tablet
vncunused=1
apic=1
acpi=1
pae=1
vcpus=1
serial = pty
on_reboot = 'restart'
on_crash= 'restart'
-Original Message-
From: Daniel P. Berrange [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 1:05 PM
To: Richard W.M. Jones
Cc: Matthew Donovan; libvir-list@redhat.com
Subject: Re: [libvirt] Using Xen config files
On Wed, Aug 20, 2008 at 04:44:04PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 20, 2008 at 11:35:17AM -0400, Matthew Donovan wrote:
It certainly looks OK, and it seems like the domain should run after
virDomainCreate. Have you tried adding a delay of 30
seconds just to
check if the domain is starting up slowly?
Yep, that debug suggests the libvirt part of creation has
completed OK.
I think if anything is going wrong, its going to be in XenD's
arena. I'd
recommend looking in /var/log/xen for any further hints of trouble
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o-
http://ovirt.org :|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF
F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] anyone implementing host device enumeration?
Hi - I'm about to start working on host device enumeration, along the (HAL-ish) lines of what was discussed back in April: https://www.redhat.com/archives/libvir-list/2008-April/msg5.html I know the xml details haven't been fully fleshed out, but there seems to be agreement that it will be a fairly direct mapping from (a subset of the) HAL info to the details that we need in the xml. Doubtless it will take a while to figure out exactly what subset suffices (and, for that matter, if everything needed is available via HAL ...), but I think the work is well-defined for some of the obvious details (discussed in the above thread) on which there's broad agreement. Is anyone working on such an implementation? Thanks, Dave -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Add success output to virsh attach/detach commands
The virsh attach-* and detach-* commands don't say
anything if the operation succeeds, which doesn't
seem very polite. The attached adds some simple
feedback.
Thanks,
Cole
commit eda28c5de3d367d001ca89ffc969fcc3c0185abb
Author: Cole Robinson [EMAIL PROTECTED]
Date: Thu Aug 21 17:59:13 2008 -0400
Report success message for virsh attach-* and detach-*
diff --git a/src/virsh.c b/src/virsh.c
index 67d9658..c22cdc4 100644
--- a/src/virsh.c
+++ b/src/virsh.c
@@ -4490,6 +4490,8 @@ cmdAttachDevice(vshControl *ctl, const vshCmd *cmd)
vshError(ctl, FALSE, _(Failed to attach device from %s), from);
virDomainFree(dom);
return FALSE;
+} else {
+vshPrint(ctl, _(Device attached successfully\n));
}
virDomainFree(dom);
@@ -4547,6 +4549,8 @@ cmdDetachDevice(vshControl *ctl, const vshCmd *cmd)
vshError(ctl, FALSE, _(Failed to detach device from %s), from);
virDomainFree(dom);
return FALSE;
+} else {
+vshPrint(ctl, _(Device detached successfully\n));
}
virDomainFree(dom);
@@ -4655,8 +4659,11 @@ cmdAttachInterface(vshControl *ctl, const vshCmd *cmd)
if (!buf) goto cleanup;
strcat(buf, /interface\n);
-if (virDomainAttachDevice(dom, buf))
+if (virDomainAttachDevice(dom, buf)) {
goto cleanup;
+} else {
+vshPrint(ctl, _(Interface attached successfully\n));
+}
ret = TRUE;
@@ -4772,8 +4779,10 @@ cmdDetachInterface(vshControl *ctl, const vshCmd *cmd)
ret = virDomainDetachDevice(dom, (char *)xmlBufferContent(xml_buf));
if (ret != 0)
ret = FALSE;
-else
+else {
+vshPrint(ctl, _(Interface detached successfully\n));
ret = TRUE;
+}
cleanup:
if (dom)
@@ -4939,6 +4948,8 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
if (virDomainAttachDevice(dom, buf))
goto cleanup;
+else
+vshPrint(ctl, _(Disk attached successfully\n));
ret = TRUE;
@@ -5046,8 +5057,10 @@ cmdDetachDisk(vshControl *ctl, const vshCmd *cmd)
ret = virDomainDetachDevice(dom, (char *)xmlBufferContent(xml_buf));
if (ret != 0)
ret = FALSE;
-else
+else {
+vshPrint(ctl, _(Disk detached successfully\n));
ret = TRUE;
+}
cleanup:
xmlXPathFreeObject(obj);
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Set correct device type when parsing input devices
In virDomainDeviceDefParse, parsing an input device
was actually setting it's type as DEVICE_DISK. The
attached patch fixes this.
Thanks,
Cole
commit 75150ac2536c427f74875fc563abf2fc06595dda
Author: Cole Robinson [EMAIL PROTECTED]
Date: Thu Aug 21 13:27:38 2008 -0400
Fix setting input device type in virDomainDeviceDefParse.
diff --git a/src/domain_conf.c b/src/domain_conf.c
index d482e68..6b23474 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -1656,7 +1656,7 @@ virDomainDeviceDefPtr
virDomainDeviceDefParse(virConnectPtr conn,
if (!(dev-data.net = virDomainNetDefParseXML(conn, node)))
goto error;
} else if (xmlStrEqual(node-name, BAD_CAST input)) {
-dev-type = VIR_DOMAIN_DEVICE_DISK;
+dev-type = VIR_DOMAIN_DEVICE_INPUT;
if (!(dev-data.input = virDomainInputDefParseXML(conn, def-os.type,
node)))
goto error;
} else if (xmlStrEqual(node-name, BAD_CAST sound)) {
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Check disk target collision when parsing domain xml
The current domain xml parsing doesn't check if disks
are specified with duplicate targets (hda etc.). The
attached patch adds a check for this.
Thanks,
Cole
commit 27df1653474738a2ce83c89e7bdb2c4f7327f9b6
Author: Cole Robinson [EMAIL PROTECTED]
Date: Thu Aug 21 14:58:04 2008 -0400
Check for duplicate disk targets when parsing domain xml.
diff --git a/src/domain_conf.c b/src/domain_conf.c
index 6b23474..ed6cc8b 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -1955,6 +1955,12 @@ static virDomainDefPtr
virDomainDefParseXML(virConnectPtr conn,
} else {
virDomainDiskDefPtr ptr = def-disks;
while (ptr) {
+if (ptr-next STREQ(disk-dst, ptr-next-dst)) {
+virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(duplicate disk target '%s'),
+ disk-dst);
+goto error;
+}
if (!ptr-next || virDomainDiskCompare(disk, ptr-next) 0) {
disk-next = ptr-next;
ptr-next = disk;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix cd eject segfault
The cdrom eject code was trying to dereference the
NULL source of an empty cdrom. Attached patch fixes
this.
Thanks,
Cole
commit 5925689b5b94b29a520dcfbc7f4f1cfa0a0a0183
Author: Cole Robinson [EMAIL PROTECTED]
Date: Thu Aug 21 17:56:25 2008 -0400
Prevent cdrom eject from segfaulting when setting new disk source.
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 06fbe55..769f34f 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2953,6 +2953,7 @@ static int qemudDomainChangeCDROM(virDomainPtr dom,
virDomainDiskDefPtr newdisk) {
struct qemud_driver *driver = (struct qemud_driver
*)dom-conn-privateData;
char *cmd, *reply, *safe_path;
+char *newsrc = NULL;
if (newdisk-src) {
safe_path = qemudEscapeMonitorArg(newdisk-src);
@@ -2972,6 +2973,13 @@ static int qemudDomainChangeCDROM(virDomainPtr dom,
}
VIR_FREE(safe_path);
+newsrc = strdup(newdisk-src);
+if (!newsrc) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ %s, _(out of memory));
+return -1;
+}
+
} else if (asprintf(cmd, eject cdrom) == -1) {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
%s, _(out of memory));
@@ -2982,11 +2990,17 @@ static int qemudDomainChangeCDROM(virDomainPtr dom,
qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
%s, _(cannot change cdrom media));
VIR_FREE(cmd);
+VIR_FREE(newsrc);
return -1;
}
VIR_FREE(reply);
VIR_FREE(cmd);
-strcpy(olddisk-src, newdisk-src);
+
+VIR_FREE(olddisk-src);
+if (newsrc) {
+olddisk-src = newsrc;
+newsrc = NULL;
+}
olddisk-type = newdisk-type;
return 0;
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Update domain xml after usb hotplug
The recently added usb hostdev and mass storage device
hotplug code doesn't append the devices to the running
guests xml if the hotplug succeeds. The attached patch
fixes this.
Thanks,
Cole
commit 8df17db8b36a2c1e8efa430a0493f66825b6b80e
Author: Cole (Work Acct) [EMAIL PROTECTED]
Date: Thu Aug 21 23:08:04 2008 -0400
Add hotplugged usb devices to running domain xml.
diff --git a/src/domain_conf.c b/src/domain_conf.c
index 3c61039..dc5eb0c 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -481,8 +481,8 @@ void virDomainRemoveInactive(virDomainObjPtr *doms,
}
#ifndef PROXY
-static int virDomainDiskCompare(virDomainDiskDefPtr a,
-virDomainDiskDefPtr b) {
+int virDomainDiskCompare(virDomainDiskDefPtr a,
+ virDomainDiskDefPtr b) {
if (a-bus == b-bus)
return virDiskNameToIndex(a-dst) - virDiskNameToIndex(b-dst);
else
diff --git a/src/domain_conf.h b/src/domain_conf.h
index b98f7f3..cfa2a90 100644
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -526,6 +526,8 @@ char *virDomainCpuSetFormat(virConnectPtr conn,
char *cpuset,
int maxcpu);
+int virDomainDiskCompare(virDomainDiskDefPtr a,
+ virDomainDiskDefPtr b);
int virDomainSaveConfig(virConnectPtr conn,
const char *configDir,
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 769f34f..9a26375 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -62,6 +62,7 @@
#include capabilities.h
#include memory.h
#include uuid.h
+#include domain_conf.h
/* For storing short-lived temporary files. */
#define TEMPDIR LOCAL_STATE_DIR /cache/libvirt
@@ -3044,6 +3045,7 @@ static int
qemudDomainAttachUsbMassstorageDevice(virDomainPtr dom, virDomainDevi
virDomainObjPtr vm = virDomainFindByUUID(driver-domains, dom-uuid);
int ret;
char *cmd, *reply;
+virDomainDiskDefPtr *dest, *prev, ptr;
if (!vm) {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
@@ -3051,6 +3053,28 @@ static int
qemudDomainAttachUsbMassstorageDevice(virDomainPtr dom, virDomainDevi
return -1;
}
+/* Find spot in domain definition where we will put the disk */
+ptr = vm-def-disks;
+prev = (vm-def-disks);
+while (ptr) {
+if (STREQ(dev-data.disk-dst, ptr-dst)) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_INTERNAL_ERROR,
+ _(duplicate disk target '%s'),
+ dev-data.disk-dst);
+return -1;
+}
+if (virDomainDiskCompare(dev-data.disk, ptr) 0) {
+dest = (ptr);
+break;
+}
+prev = (ptr-next);
+ptr = ptr-next;
+}
+
+if (!ptr) {
+dest = prev;
+}
+
ret = asprintf(cmd, usb_add disk:%s, dev-data.disk-src);
if (ret == -1) {
qemudReportError(dom-conn, NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
@@ -3059,7 +3083,7 @@ static int
qemudDomainAttachUsbMassstorageDevice(virDomainPtr dom, virDomainDevi
if (qemudMonitorCommand(driver, vm, cmd, reply) 0) {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
- %s, _(cannot attach usb device));
+ %s, _(cannot attach usb disk));
VIR_FREE(cmd);
return -1;
}
@@ -3070,11 +3094,16 @@ static int
qemudDomainAttachUsbMassstorageDevice(virDomainPtr dom, virDomainDevi
if (strstr(reply, Could not add )) {
qemudReportError (dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
%s,
- _(adding usb device failed));
+ _(adding usb disk failed));
VIR_FREE(reply);
VIR_FREE(cmd);
return -1;
}
+
+/* Actually update the xml */
+dev-data.disk-next = *dest;
+*prev = dev-data.disk;
+
VIR_FREE(reply);
VIR_FREE(cmd);
return 0;
@@ -3125,6 +3154,11 @@ static int qemudDomainAttachHostDevice(virDomainPtr dom,
virDomainDeviceDefPtr d
VIR_FREE(cmd);
return -1;
}
+
+/* Update xml */
+dev-data.hostdev-next = vm-def-hostdevs;
+vm-def-hostdevs = dev-data.hostdev;
+
VIR_FREE(reply);
VIR_FREE(cmd);
return 0;
@@ -3167,7 +3201,7 @@ static int qemudDomainAttachDevice(virDomainPtr dom,
ret = qemudDomainAttachHostDevice(dom, dev);
} else {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_NO_SUPPORT,
- %s, _(this devicetype cannot be attached));
+ %s, _(this device type cannot be attached));
ret = -1;
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
