6:39 p.m.
---------- Forwarded message ----------
From: Stefano Ricci <sfn.rcc(a)gmail.com>
Date: 2016-10-11 12:35 GMT+02:00
Subject: Re: [libvirt-users] Problems connecting to the libvirtd server
To: Michal Privoznik <mprivozn(a)redhat.com>
There is not AppArmor and SElinux is disabled.
The permits of the sock are as follows:
libvirt-sock-admin 0700 (rwx) root: root
libvirt-sock 0700 (rwx) root: root
libvirt-sock-ro 0777 (rwxrwxrwx) root: root
The libvirtd process runs with the root user.
Below you will find the link to the requested log:
http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG
= 1 virsh -c qemu: /// system list --all)
Stefano
2016-10-11 11:04 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com>:
On 10.10.2016 18:36, Stefano Ricci wrote:
> Hello everyone
> I do not know if it is correct address this mailing lists but I can
> not use libvirt.
> I run compile libvirt version 2.2.0 into environment lfs stable with
> qemu 2.7.0 and have not had any problems.
> The program when it starts not report any errors in the log, with
> activated debug level file.
> Only when you try to connect with the following command virsh -c
> qemu:///system remains hung without reporting any error either in the
> logs that screen.
> The command virsh -c test:///default list instead concludes on a regular basis.
> I attach the file libvirt.log and libvirt.conf
Interesting. Maybe something else is causing the problem? Is there an
AppArmor running? What are the socket perms? Can you attach client debug
logs? (well, maybe paste them somewhere to pastebin-like service)
http://wiki.libvirt.org/page/DebugLogs
Michal
1:06 p.m.
New subject: [libvirt-users] Fwd: Problems connecting to the libvirtd server
On 11.10.2016 18:39, Stefano Ricci wrote:
---------- Forwarded message ----------
From: Stefano Ricci <sfn.rcc(a)gmail.com>
Date: 2016-10-11 12:35 GMT+02:00
Subject: Re: [libvirt-users] Problems connecting to the libvirtd server
To: Michal Privoznik <mprivozn(a)redhat.com>
[Please don't top post on technical lists]
There is not AppArmor and SElinux is disabled.
The permits of the sock are as follows:
libvirt-sock-admin 0700 (rwx) root: root
libvirt-sock 0700 (rwx) root: root
libvirt-sock-ro 0777 (rwxrwxrwx) root: root
The libvirtd process runs with the root user.
Okay, the permissions look okay.
Below you will find the link to the requested log:
http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG
= 1 virsh -c qemu: /// system list --all)
And from the client logs it looks like client is trying to connect but
the daemon is not replying. So client just hangs waiting for server
reply. So I've looked into daemon logs and found this:
2016-10-10 12:10:39.138+0000: 1383: error : virPidFileAcquirePath:422 :
Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile':
Risorsa temporaneamente non disponibile
(with my little Italian knowledge, this is Resource temporary unavailable)
This suggests that there might be a different libvirt daemon running.
Can you confirm that?
Michal
4:06 p.m.
New subject: [libvirt-users] Fwd: Problems connecting to the libvirtd server
> ---------- Forwarded message ----------
> From: Stefano Ricci <sfn.rcc(a)gmail.com>
> Date: 2016-10-11 12:35 GMT+02:00
> Subject: Re: [libvirt-users] Problems connecting to the libvirtd server
> To: Michal Privoznik <mprivozn(a)redhat.com>
>
[Please don't top post on technical lists]
Sorry I was wrong
>
> There is not AppArmor and SElinux is disabled.
> The permits of the sock are as follows:
> libvirt-sock-admin 0700 (rwx) root: root
> libvirt-sock 0700 (rwx) root: root
> libvirt-sock-ro 0777 (rwxrwxrwx) root: root
> The libvirtd process runs with the root user.
Okay, the permissions look okay.
Good
>
> Below you will find the link to the requested log:
> http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG
> = 1 virsh -c qemu: /// system list --all)
And from the client logs it looks like client is trying to connect but
the daemon is not replying. So client just hangs waiting for server
reply. So I've looked into daemon logs and found this:
2016-10-10 12:10:39.138+0000: 1383: error : virPidFileAcquirePath:422 :
Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile':
Risorsa temporaneamente non disponibile
(with my little Italian knowledge, this is Resource temporary unavailable)
This suggests that there might be a different libvirt daemon running.
Can you confirm that?
If I do a ps I am one libvirtd daemon and one of qemu and
/var/lib/libvirt/qemu/capabilities.pidfile file exists
The file contains the correct PID of the process qemu.
Stefano
2016-10-12 7:06 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com>:
On 11.10.2016 18:39, Stefano Ricci wrote:
> ---------- Forwarded message ----------
> From: Stefano Ricci <sfn.rcc(a)gmail.com>
> Date: 2016-10-11 12:35 GMT+02:00
> Subject: Re: [libvirt-users] Problems connecting to the libvirtd server
> To: Michal Privoznik <mprivozn(a)redhat.com>
>
[Please don't top post on technical lists]
>
> There is not AppArmor and SElinux is disabled.
> The permits of the sock are as follows:
> libvirt-sock-admin 0700 (rwx) root: root
> libvirt-sock 0700 (rwx) root: root
> libvirt-sock-ro 0777 (rwxrwxrwx) root: root
> The libvirtd process runs with the root user.
Okay, the permissions look okay.
>
> Below you will find the link to the requested log:
> http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG
> = 1 virsh -c qemu: /// system list --all)
And from the client logs it looks like client is trying to connect but
the daemon is not replying. So client just hangs waiting for server
reply. So I've looked into daemon logs and found this:
2016-10-10 12:10:39.138+0000: 1383: error : virPidFileAcquirePath:422 :
Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile':
Risorsa temporaneamente non disponibile
(with my little Italian knowledge, this is Resource temporary unavailable)
This suggests that there might be a different libvirt daemon running.
Can you confirm that?
Michal
4:43 p.m.
New subject: [libvirt-users] Fwd: Problems connecting to the libvirtd server
On 12.10.2016 16:06, Stefano Ricci wrote:
>> ---------- Forwarded message ----------
>> From: Stefano Ricci <sfn.rcc(a)gmail.com>
>> Date: 2016-10-11 12:35 GMT+02:00
>> Subject: Re: [libvirt-users] Problems connecting to the libvirtd server
>> To: Michal Privoznik <mprivozn(a)redhat.com>
>>
>
> [Please don't top post on technical lists]
Sorry I was wrong
>>
>> There is not AppArmor and SElinux is disabled.
>> The permits of the sock are as follows:
>> libvirt-sock-admin 0700 (rwx) root: root
>> libvirt-sock 0700 (rwx) root: root
>> libvirt-sock-ro 0777 (rwxrwxrwx) root: root
>> The libvirtd process runs with the root user.
>
> Okay, the permissions look okay.
Good
>>
>> Below you will find the link to the requested log:
>> http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG
>> = 1 virsh -c qemu: /// system list --all)
>
> And from the client logs it looks like client is trying to connect but
> the daemon is not replying. So client just hangs waiting for server
> reply. So I've looked into daemon logs and found this:
>
> 2016-10-10 12:10:39.138+0000: 1383: error : virPidFileAcquirePath:422 :
> Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile':
> Risorsa temporaneamente non disponibile
>
> (with my little Italian knowledge, this is Resource temporary unavailable)
>
> This suggests that there might be a different libvirt daemon running.
> Can you confirm that?
If I do a ps I am one libvirtd daemon and one of qemu and
/var/lib/libvirt/qemu/capabilities.pidfile file exists
The file contains the correct PID of the process qemu.
Okay, so what's the status of the qemu process? Because what might be
happening here is that qemu driver is still starting up, so it is not
accepting connections just yet. And because qemu process it was talking
to (whilst fetching the caps) hung up, the driver basically failed to
start (and is still in startup phase).
Michal
7:16 p.m.
New subject: [libvirt-users] Fwd: Problems connecting to the libvirtd server
I checked with qmp and your consideration was correct, the status of
qemu process is in prelaunch and running equals false.
But I do not understand why
Stefano
2016-10-12 10:43 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com>:
On 12.10.2016 16:06, Stefano Ricci wrote:
>>> ---------- Forwarded message ----------
>>> From: Stefano Ricci <sfn.rcc(a)gmail.com>
>>> Date: 2016-10-11 12:35 GMT+02:00
>>> Subject: Re: [libvirt-users] Problems connecting to the libvirtd server
>>> To: Michal Privoznik <mprivozn(a)redhat.com>
>>>
>>
>> [Please don't top post on technical lists]
> Sorry I was wrong
>
>>>
>>> There is not AppArmor and SElinux is disabled.
>>> The permits of the sock are as follows:
>>> libvirt-sock-admin 0700 (rwx) root: root
>>> libvirt-sock 0700 (rwx) root: root
>>> libvirt-sock-ro 0777 (rwxrwxrwx) root: root
>>> The libvirtd process runs with the root user.
>>
>> Okay, the permissions look okay.
> Good
>
>>>
>>> Below you will find the link to the requested log:
>>> http://pastebin.com/0jtpWU0h (libvirt_client.log command LIBVIRT_DEBUG
>>> = 1 virsh -c qemu: /// system list --all)
>>
>> And from the client logs it looks like client is trying to connect but
>> the daemon is not replying. So client just hangs waiting for server
>> reply. So I've looked into daemon logs and found this:
>>
>> 2016-10-10 12:10:39.138+0000: 1383: error : virPidFileAcquirePath:422 :
>> Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile':
>> Risorsa temporaneamente non disponibile
>>
>> (with my little Italian knowledge, this is Resource temporary unavailable)
>>
>> This suggests that there might be a different libvirt daemon running.
>> Can you confirm that?
> If I do a ps I am one libvirtd daemon and one of qemu and
> /var/lib/libvirt/qemu/capabilities.pidfile file exists
> The file contains the correct PID of the process qemu.
Okay, so what's the status of the qemu process? Because what might be
happening here is that qemu driver is still starting up, so it is not
accepting connections just yet. And because qemu process it was talking
to (whilst fetching the caps) hung up, the driver basically failed to
start (and is still in startup phase).
Michal
8:57 a.m.
New subject: [libvirt-users] Fwd: Problems connecting to the libvirtd server
On 12.10.2016 19:16, Stefano Ricci wrote:
I checked with qmp and your consideration was correct, the status
of
qemu process is in prelaunch and running equals false.
But I do not understand why
[Please don't top post on technical lists]
Well, I don't have any idea either. I mean, the daemon logs you provided
are from the second run of libvirtd. Maybe this is qemu or kernel bug?
If you kill the stalled process and then start libvirtd again, can you
connect then or does it still hang?
Michal
12:08 a.m.
New subject: [libvirt-users] Fwd: Problems connecting to the libvirtd server
it does still hang.
The strange thing is that I launched qemu, without libvirtd,
independently creating a linux virtual machine, functions regularly
and reading the state with qmp is regularly running.
Stefano
2016-10-13 2:57 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com>:
On 12.10.2016 19:16, Stefano Ricci wrote:
> I checked with qmp and your consideration was correct, the status of
> qemu process is in prelaunch and running equals false.
> But I do not understand why
[Please don't top post on technical lists]
Well, I don't have any idea either. I mean, the daemon logs you provided
are from the second run of libvirtd. Maybe this is qemu or kernel bug?
If you kill the stalled process and then start libvirtd again, can you
connect then or does it still hang?
Michal
12:48 a.m.
New subject: [libvirt-users] Fwd: Problems connecting to the libvirtd server
I did more tests and if kill the qemu process without stopping
libvirtd and relaunching it with the following command
/usr/bin/qemu-system-x86_64 -S --no-user-config -nodefaults -nographic
-M none -qmp unix: /var /lib /libvirt /qemu
/capabilities.monitor.sock,server, nowait -pidfile
/var/lib/libvirt/qemu/capabilities.pidfile -daemonize, then virsh
working correctly and connects.
The command used to launch qemu is used by libvirtd automatically
taken by the ps -a | grep qemu.
However checking the status of qemu process with qmp is always in
prelaunch and running is false, even when it works.
When restart libvirtd back does it still hangs.
2016-10-13 18:08 GMT+02:00 Stefano Ricci <sfn.rcc(a)gmail.com>:
it does still hang.
The strange thing is that I launched qemu, without libvirtd,
independently creating a linux virtual machine, functions regularly
and reading the state with qmp is regularly running.
Stefano
2016-10-13 2:57 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com>:
> On 12.10.2016 19:16, Stefano Ricci wrote:
>> I checked with qmp and your consideration was correct, the status of
>> qemu process is in prelaunch and running equals false.
>> But I do not understand why
>
> [Please don't top post on technical lists]
>
> Well, I don't have any idea either. I mean, the daemon logs you provided
> are from the second run of libvirtd. Maybe this is qemu or kernel bug?
> If you kill the stalled process and then start libvirtd again, can you
> connect then or does it still hang?
>
> Michal
2886
days inactive
2888
days old
7 comments
2 participants
participants (2)
-
Michal Privoznik -
Stefano Ricci