10:32 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3:24 a.m.
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
3:47 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
7:22 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
7:31 a.m.
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
9:37 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2:15 a.m.
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
7:09 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
8:27 a.m.
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
7:51 a.m.
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 :|
4581
days inactive
4582
days old
9 comments
5 participants
participants (5)
-
Daniel P. Berrange -
Eric Blake -
Jiri Denemark -
Martin Kletzander -
Osier Yang