Here is the backtrace of the libvirt process just started
https://pastebin.com/R66myzFp
Stefano
2017-04-27 15:12 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com>:
On 04/27/2017 03:11 PM, Michal Privoznik wrote:
> On 04/27/2017 02:02 PM, Stefano Ricci wrote:
>> Hello everyone
>> I come back to ask for a hand to solve a problem that has affected me
>> since October 2016 and I have not yet solved using libvirt.
>> I thought I would solve it by going to a 4.9.x kernel with qemu
>> 2.8.1.1 and with libvirt 3.2.0.
>> Compile it all in a stable LFS environment version 7.9 and that all
>> checks pass without errors.
>> The strange thing is that the libvirtd process starts without errors
>> but has arrived at the qemu process launch to understand the system's
>> capabilities freezes until the following process is killed
>> /usr/bin/qemu-system-x86_64 -S -none-user-config -nodefaults
>> -nographic -machine none, accel = kvm: tcg -qmp unix:
>>
/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait-pidfile/var/lib/libvirt/qemu/capabilities.Pidfile
>> -daemonize, since that time libvirtd resumes running and can be used
>> with virsh.
>> Performing qemu independently of libvirt works regularly, creates and
>> runs virtual machines smoothly.
>>
>> Thanks in advance
>> Stefano Ricci
>>
>
>
> I think I've read this somewhere else, but I don't remember where.
> Anyway, my rough guess is that libvirtd is stuck on refreshing the qemu
> capabilities. This is done on the daemon startup and until it finishes,
> no API can be practically executed. Well, for the driver in question (in
> this case qemu). Other driver should work just fine.
>
> Can you please attach debugger and get the backtrace for us?
>
> gdb -p $(pgrep libvirtd)
>
> ...
> ...
> (gdb) bt
I mean more 't a a bt' which stands for 'thread apply all backtrace'
=>
get backtrace for all the threads. Thanks.
Michal