[libvirt-users] Fwd: Problems connecting to the libvirtd server

[Stefano Ricci]

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 at redhat.com>:
> On 12.10.2016 16:06, Stefano Ricci wrote:
>>>> ---------- Forwarded message ----------
>>>> From: Stefano Ricci <sfn.rcc at 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 at 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