On 04/28/2015 09:21 PM, Matthew Schumacher wrote:
On 04/28/2015 05:13 PM, Laine Stump wrote:
Bah. Your debug symbols aren't enough to give a full stack trace - what I was really looking for was those things marked as ??.
However, your debug output shows several things leading up tothe qemuProcessStop that might have been the reason for it being called:
1) virStorageFileBackendFileReadHeader() complains that there is no medium in /dev/sr0 (i.e. no disk in the CD drive) (this was actually in your much more abbreviated log in an earlier message, but for some reason I skipped over it :-/)
2) libvirt sends the following command to qemu:
{"execute":"block-commit","arguments":{"device":"bogus"},"id":"libvirt-4"}
and gets back this error:
{"id": "libvirt-4", "error": {"class": "DeviceNotFound", "desc": "Device 'bogus' not found"}}
Since (1) actually generates a libvirt error log, that is what I would look into first.
Thanks Laine,
Confirmed, if I:
virsh attach-disk test '' hdc --type cdrom
Then I can kick libvirtd all I want and it doesn't take out my domain.
So now that that is fixed, I'm back to trying to figure out out why blockcopy --wait won't actually wait, as it's hard to migrate domains from one storage to another while needing to continually call blockjob to see if we are 100% mirroring.
I posted plenty of debug here: https://bugzilla.redhat.com/attachment.cgi?id=1019911
That is an attachment to: https://bugzilla.redhat.com/show_bug.cgi?id=1210903 and it looks like Eric noticed it and has commented in the bug.
I wonder if the issue isn't obvious to you since you know a bit more about how libvirt interacts with qemu than I do.
Nope. I am ignorant about all the new block operations, but if Eric is on the case you're in good hands.
Also, is there a link so some documentation that describes all of the json going between libvirt and qemu?
If there is, I guess it would be somewhere in qemu documentation, maybe on linux-kvm.org?