search for: qemuprocesskill

...> 1) what version of libvirt are you running and on what distro? > > 2) can you reproduce this reliably? > > 3) If the answer to 2 is "yes", do you have the libvirt-debuginfo > package installed, and can you stop libvirtd, then run it under gdb with > a breakpoint at qemuProcessKill? Once you hit that breakpoint, you could > get a backtrace with the "bt" command and that might give us some useful > info about where it is coming from. > > Oh, by the way, are these perhaps transient domains started with > virDomainCreate*? Or are they standard persistent...

...ted. I simply started libvirtd, started my vm, killed libvirtd, then started it again with gdb in foreground mode with the breakpoint set. I got a ton of debug info that I posted here: http://www.aptalaska.net/~matt.s/libvirt.txt but the backtrace is simply: Breakpoint 1, 0x00007fffc72a0240 in qemuProcessKill () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so (gdb) bt #0 0x00007fffc72a0240 in qemuProcessKill () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so #1 0x00007fffc72a19cd in qemuProcessStop () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so #2...

...debug : virFileClose:102 : Closed fd 18 2015-04-20 23:50:20.387+0000: 25373: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x7fb8d0000bd0 2015-04-20 23:50:20.387+0000: 25373: debug : qemuProcessKill:5047 : vm=0x7fb8cc0d8510 name=test pid=25245 flags=5 2015-04-20 23:50:20.387+0000: 25373: debug : virProcessKillPainfully:352 : vpid=25245 force=1 2015-04-20 23:50:20.387+0000: 25298: debug : virEventPollRunOnce:650...

Restarting libvirtd doesn't change the situation. But looking into the logs I see the following: - Last lines in /var/log/libvirt/libvirtd.log: 2016-07-05 13:26:42.792+0000: 24552: warning : qemuProcessKill:4419 : Timed out waiting after SIGKILL to process 48301 2016-07-05 13:26:42.792+0000: 24552: error : qemuDomainDestroyFlags:2120 : operation failed: failed to kill qemu process with SIGTERM - lookup for process 48301: [root@lpextvms003c ~]# ps -ef | grep 48301 root 1114 24243 0 16:02 pts/1...

...: Closed > fd 18 > 2015-04-20 23:50:20.387+0000: 25373: info : virObjectUnref:259 : > OBJECT_UNREF: > obj=0x7fb8d0000bd0 > 2015-04-20 23:50:20.387+0000: 25373: debug : qemuProcessKill:5047 : > vm=0x7fb8cc0d8510 name=test pid=25245 > flags=5 Well, this is when the qemu process is killed (I'm pretty clever, eh? :-) I have 3 questions: 1) what version of libvirt are you running and on what distro? 2) can you reproduce this reliably? 3)...

...libvirt are you running and on what distro? >> >> 2) can you reproduce this reliably? >> >> 3) If the answer to 2 is "yes", do you have the libvirt-debuginfo >> package installed, and can you stop libvirtd, then run it under gdb with >> a breakpoint at qemuProcessKill? Once you hit that breakpoint, you could >> get a backtrace with the "bt" command and that might give us some useful >> info about where it is coming from. >> >> Oh, by the way, are these perhaps transient domains started with >> virDomainCreate*? Or are they...

...my vm, killed libvirtd, then started > it again with gdb in foreground mode with the breakpoint set. > > I got a ton of debug info that I posted here: > > http://www.aptalaska.net/~matt.s/libvirt.txt > > but the backtrace is simply: > > Breakpoint 1, 0x00007fffc72a0240 in qemuProcessKill () from > /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so > (gdb) bt > #0 0x00007fffc72a0240 in qemuProcessKill () from > /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so > #1 0x00007fffc72a19cd in qemuProcessStop () from > /usr/lib64/libvirt/connection-dr...

On Tue, Jul 05, 2016 at 04:20:58PM +0200, Roland Everaert wrote: > Restarting libvirtd doesn't change the situation. > > But looking into the logs I see the following: > > - Last lines in /var/log/libvirt/libvirtd.log: > > 2016-07-05 13:26:42.792+0000: 24552: warning : qemuProcessKill:4419 : Timed > out waiting after SIGKILL to process 48301 > 2016-07-05 13:26:42.792+0000: 24552: error : qemuDomainDestroyFlags:2120 : > operation failed: failed to kill qemu process with SIGTERM > > - lookup for process 48301: > > [root@lpextvms003c ~]# ps -ef | grep 48301 &...

Hello, We are currently facing a strange situation. One of our VM is shown by 'virsh list' as in state "in shutdown" but there is no more a qemu-kvm process linked to it. So we have a few questions: 1. What does means the state in shutdown (I have not found much information about it)? 2. How to cleanly "shutdown" the vm, or more correctly, clean the status in

List, I was under the impression that I could restart libvirtd without it destroying my VMs, but am not finding that to be true. When I killall libvirtd then my VM's keep running, but then when I start libvirtd it calls qemuDomainObjEndJob:1542 : Stopping job: modify (async=none vm=0x7fb8cc0d8510 name=test) and my domain gets whacked. Any way to disable this behavior? Also, while I'm