Re: [Qemu-block] I/O errors reported to guest for raw-image-file backed /dev/vda - but host sees no I/O errors
On 04/21/2016 05:54 PM, Lutz Vieweg wrote: And indeed, the errors occured exactly at the time a backup procedure was preparing a read-only snapshot with "btrfs subvolume snapshot -r" - so until I can upgrade to a mainline kernel including the fix, I'll pause the qemu process while the "btrfs subvolume snapshot -r" runs. Alas, this seems not to be sufficient to get rid of the symptom easily - I guess that some of the "pwrite"s are executed asynchronously, at a time when the qemu emulation is already in "pause" mode. Will retry with some safeguard sleep time between the "stop" to the monitor and the creation of the snapshot. Regards, Lutz Vieweg
Re: [Qemu-block] [Qemu-devel] I/O errors reported to guest for raw-image-file backed /dev/vda - but host sees no I/O errors
On 04/22/2016 03:16 AM, Fam Zheng wrote: On Thu, 04/21 17:54, Lutz Vieweg wrote: Nevertheless, I think qemu could be somewhat more verbose, reporting when and why it stops emulation. Something like a message to the monitor or to standard out would be helpful to start with... QEMU does report an error message to connected monitor if configured to. See the werror= and rerror= options. I looked up these options, but both the man-page and the source code did not reveal any option to emit error messages to the qemu monitor - the "report" option value just causes the guest to see the error code, but that doesn't mean a message to the qemu monitor. Regards, Lutz Vieweg
Re: [Qemu-block] [Qemu-devel] I/O errors reported to guest for raw-image-file backed /dev/vda - but host sees no I/O errors
On 04/20/2016 01:50 PM, Kevin Wolf wrote: To catch all possible write failures, I think pwrite, pwritev and possibly fdatasync need to be considered. I've now a strace -f -p 10727 -e trace=pwrite,pwritev,fdatasync,file -t 2>&1 | gzip -1 -c >trace.gz attached to the qemu-process. If the incident rate stays the same, by tomorrow I should be able to correlate newly emitted I/O-errors in the guest with that log. Regards, Lutz Vieweg
