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
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
