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
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.
Also, is there a link so some documentation that describes all of the
json going between libvirt and qemu?
Thanks for your help!
schu