[libvirt] pointless time-consuming test 'virsh-all'
The command 'make -C tests check' takes forever, because it is calling this lengthy virsh command and ignoring the failures: $ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory real 0m21.070s user 0m0.027s sys 0m0.036s The test looks quite broken - ALL it is currently doing is wasting 21 seconds on this one iteration, because it ignores output and exit status (what else _is_ there, besides effects to the file system)? Any volunteers to clean this test up into something that actually does something useful? -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 06/07/2012 05:32 AM, Eric Blake wrote:
The command 'make -C tests check' takes forever, because it is calling this lengthy virsh command and ignoring the failures:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
real 0m21.070s user 0m0.027s sys 0m0.036s
The test looks quite broken - ALL it is currently doing is wasting 21 seconds on this one iteration, because it ignores output and exit status (what else _is_ there, besides effects to the file system)?
Any volunteers to clean this test up into something that actually does something useful?
I'd like to help out but I don't see any problem. When I run 'make -C tests check', there is no test that takes more than a second and the whole make check is done in under 50 seconds. This is what I get when running the same as you did: $ time tools/virsh -c test:///default connect real 0m0.048s user 0m0.024s sys 0m0.022s Let me know if there are any details I missed. Have a nice day, Martin
On 2012年06月07日 16:24, Martin Kletzander wrote:
On 06/07/2012 05:32 AM, Eric Blake wrote:
The command 'make -C tests check' takes forever, because it is calling this lengthy virsh command and ignoring the failures:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
real 0m21.070s user 0m0.027s sys 0m0.036s
The test looks quite broken - ALL it is currently doing is wasting 21 seconds on this one iteration, because it ignores output and exit status (what else _is_ there, besides effects to the file system)?
Any volunteers to clean this test up into something that actually does something useful?
I'd like to help out but I don't see any problem. When I run 'make -C tests check', there is no test that takes more than a second and the whole make check is done in under 50 seconds.
This is what I get when running the same as you did:
$ time tools/virsh -c test:///default connect
real 0m0.048s user 0m0.024s sys 0m0.022s
I don't see the problem either, $ time tools/virsh -c test:///default connect real 0m0.083s user 0m0.031s sys 0m0.031s
Let me know if there are any details I missed.
Have a nice day, Martin
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 06/07/2012 02:24 AM, Martin Kletzander wrote:
On 06/07/2012 05:32 AM, Eric Blake wrote:
The command 'make -C tests check' takes forever, because it is calling this lengthy virsh command and ignoring the failures:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
real 0m21.070s user 0m0.027s sys 0m0.036s
The test looks quite broken - ALL it is currently doing is wasting 21 seconds on this one iteration, because it ignores output and exit status (what else _is_ there, besides effects to the file system)?
This part is still true - the test in its current incarnation is wasted, because it ignores output and exit status, even if you don't hit a delay.
$ time tools/virsh -c test:///default connect
real 0m0.048s
Odd. Looks like I have some debugging to do, then (it might be related to how I have my $HOME mounted). -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 06/07/2012 02:22 PM, Eric Blake wrote:
On 06/07/2012 02:24 AM, Martin Kletzander wrote:
On 06/07/2012 05:32 AM, Eric Blake wrote:
The command 'make -C tests check' takes forever, because it is calling this lengthy virsh command and ignoring the failures:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
real 0m21.070s user 0m0.027s sys 0m0.036s
The test looks quite broken - ALL it is currently doing is wasting 21 seconds on this one iteration, because it ignores output and exit status (what else _is_ there, besides effects to the file system)?
This part is still true - the test in its current incarnation is wasted, because it ignores output and exit status, even if you don't hit a delay.
I don't exactly know how these tests work, so I'll have a look at it, but I don't promise anything.
$ time tools/virsh -c test:///default connect
real 0m0.048s
Odd. Looks like I have some debugging to do, then (it might be related to how I have my $HOME mounted).
I'm compiling and testing the code with '--system' specified, so that might have something to do with it. I'll try some magic and in case you want me to try something, just ping me ;) Martin
On 06/07/2012 06:31 AM, Martin Kletzander wrote:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
Odd. Looks like I have some debugging to do, then (it might be related to how I have my $HOME mounted).
I'm compiling and testing the code with '--system' specified, so that might have something to do with it. I'll try some magic and in case you want me to try something, just ping me ;)
Are you running the test as root or as yourself? Also, what does 'tools/virsh uri' print? I think the problem here is that 'connect' without arguments tries to connect to the default URI instead of reconnecting to the -c test:///default URI; in my case, the default is qemu:///session when run as myself, and that is the part that is failing, because the socket is not being created in a timely manner. Obviously, our testsuite should NOT be trying to connect to qemu:///session, so the fix for this test would be to update it to call 'connect test:///default' instead of plain 'connect'. That sort of implies that we should have a lookup table of extra args to pass to any given virsh command (I'm comparing this to the help-version test of coreutils, http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/misc/help-version, which serves as a good example of how to run sanity checking on a long list of programs where only a subset of the programs need special-case handling for invocation with different than normal arguments). -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 06/07/2012 04:37 PM, Eric Blake wrote:
On 06/07/2012 06:31 AM, Martin Kletzander wrote:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
Odd. Looks like I have some debugging to do, then (it might be related to how I have my $HOME mounted).
I'm compiling and testing the code with '--system' specified, so that might have something to do with it. I'll try some magic and in case you want me to try something, just ping me ;)
Are you running the test as root or as yourself? Also, what does 'tools/virsh uri' print? I think the problem here is that 'connect'
I'm running it as myself, but because I have qemu:///system set as default in libvirt.conf (and have the rights), it connects successfully. If I stop the daemon, however, it fails, but immediately: $ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory real 0m0.045s user 0m0.021s sys 0m0.023s There is still no waiting.
without arguments tries to connect to the default URI instead of reconnecting to the -c test:///default URI; in my case, the default is qemu:///session when run as myself, and that is the part that is failing, because the socket is not being created in a timely manner.
Obviously, our testsuite should NOT be trying to connect to qemu:///session, so the fix for this test would be to update it to call 'connect test:///default' instead of plain 'connect'. That sort of
I'd suspect that 'virsh -c <uri> connect' connects to <uri> (maybe twice, but still the same URI). Maybe there could be a fix that the '-c' parameter sets the default uri, because 'virsh -c <uri> uri' prints out '<uri>' and also because it seems *very* unintuitive to me that 'virsh -c test:///default "connect; uri"' prints out something else than 'virsh -c test:///default uri'.
implies that we should have a lookup table of extra args to pass to any given virsh command (I'm comparing this to the help-version test of coreutils, http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/misc/help-version, which serves as a good example of how to run sanity checking on a long list of programs where only a subset of the programs need special-case handling for invocation with different than normal arguments).
And this looks good as well. Simple and suits it's purpose. Martin
On 06/08/2012 01:15 AM, Martin Kletzander wrote:
I'd suspect that 'virsh -c <uri> connect' connects to <uri> (maybe twice, but still the same URI). Maybe there could be a fix that the '-c' parameter sets the default uri, because 'virsh -c <uri> uri' prints out '<uri>' and also because it seems *very* unintuitive to me that 'virsh -c test:///default "connect; uri"' prints out something else than 'virsh -c test:///default uri'.
That indeed sounds like a good idea. It doesn't solve my failure to connect to qemu:///session (looks like I have a debugging session to run), but should speed up the testsuite. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Jun 07, 2012 at 06:22:12 -0600, Eric Blake wrote:
On 06/07/2012 02:24 AM, Martin Kletzander wrote:
On 06/07/2012 05:32 AM, Eric Blake wrote:
The command 'make -C tests check' takes forever, because it is calling this lengthy virsh command and ignoring the failures:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
real 0m21.070s user 0m0.027s sys 0m0.036s
The test looks quite broken - ALL it is currently doing is wasting 21 seconds on this one iteration, because it ignores output and exit status (what else _is_ there, besides effects to the file system)?
This part is still true - the test in its current incarnation is wasted, because it ignores output and exit status, even if you don't hit a delay.
$ time tools/virsh -c test:///default connect
real 0m0.048s
Odd. Looks like I have some debugging to do, then (it might be related to how I have my $HOME mounted).
I saw similar hang during the test when libvirtd was running but not responding (trapped in a gdb session, for example). However, it's much longer than 21 seconds in that case :-) I wonder why test:/// uri ever tries to connect anywhere... isn't that internal to libvirt and present in all clients? Jirka
On Wed, Jun 06, 2012 at 09:32:08PM -0600, Eric Blake wrote:
The command 'make -C tests check' takes forever, because it is calling this lengthy virsh command and ignoring the failures:
$ time tools/virsh -c test:///default connect error: Failed to connect to the hypervisor error: Failed to connect socket to '/run/user/eblake/libvirt/libvirt-sock': No such file or directory
real 0m21.070s user 0m0.027s sys 0m0.036s
The test looks quite broken - ALL it is currently doing is wasting 21 seconds on this one iteration, because it ignores output and exit status (what else _is_ there, besides effects to the file system)?
Woah, you are requesting the 'test' URI which should be 100% client side, but for some reason it is trying to connect to libvirtd. That is the primary bug here. The secondary issue is why it takes 20 seconds to fail to connect. I suspect that the 'libvirtd' binary in your path is from an older release that uses $HOME/.libvirt/libvirt-sock for the session daemon. So libvirt is repeatedly trying to autospawn libvirtd but it never listens on the socket it expects. In normal deployments thus should never be a problem, but in test suite, we should already be setting $PATH to include the locally built libvirtd first. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (5)
-
Daniel P. Berrange -
Eric Blake -
Jiri Denemark -
Martin Kletzander -
Osier Yang