[libvirt-users] QemuDomainObjEndJob called when libvirtd is started and libvirt insists qemu is using the wrong disk source.

[Laine Stump]

On 04/21/2015 05:53 PM, Matthew Schumacher wrote:
> On 04/20/2015 05:42 PM, Laine Stump wrote:
>> 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) 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 domains defined with
>> virDomainDefineXML?
>>
>> (Also, I'll just mention that qemuProcessKill() is called from
>> qemuProcessStop(), and I notice that is called in a couple places
>> related to snapshot create and revert which you mentioned in the
>> original message. Since this isn't normal behavior, and the snapshot
>> stuff is under active development, I wonder if this is related...)
> Laine,
>
> First, thanks for your help, I appreciate it.  Your questions:
>
> 1.  # libvirtd -V
> libvirtd (libvirt) 1.2.14
>
> 2.  I can reproduce this every time.
>
> 3.  I compile it myself, so I'll work on getting a libvirt-debug build
> going.


If you're compiling yourself, then you should be all set to run under
gdb. libvirt-debuginfo is just a separate subpackage that contains all
the symbol and line number info from the build so that backtraces in gdb
make sense. Try attaching gdb to the libvirtd process and do something
like "thread apply all bt" - if you see function/argument/file names and
line numbers, then you already have the symbols available.

>
> So this is compiled on Slackware64-14.1 as I prefer a more bsd linux and
> like the simplicity of a traditional init, as well as the ability to
> cook this down into a very simple usb based distro not unlike slax.

Occasionally there are cases where libvirtd terminates guests on restart
due to some failure to parse the guest's status XML, inability to
connect to the guest's qemu monitor, or some other thing that would
render the guest inaccessible. We of course want to eliminate as many of
those situations as possible, so we would love to see the backtrace you
can get from gdb.