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) btI mean more 't a a bt' which stands for 'thread apply all backtrace' => get backtrace for all the threads. Thanks. Michal
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@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
On 04/27/2017 04:31 PM, Stefano Ricci wrote:> Here is the backtrace of the libvirt process just started[Just a side note, you shouldn't top post on technical lists. Gmail sucks at this.]> > https://pastebin.com/R66myzFpLooks like libvirtd is trying to spawn /usr/bin/qemu-system-x86_64 but it takes ages to init. In the debug logs you might see the actual command line that libvirt tries to execute. You can try running it by hand and see if it takes about the same time. If so, then it's a qemu bug. http://wiki.libvirt.org/page/DebugLogs Michal