Thanks for the confirmation. I guess a limitation of the current approach, is
that there is no way to differentiate between retrying for transient errors
(NFS error not responding) versus some other hard error that gets mapped to EIO
(perhaps requiring real operator assistance). Pretty much any unexpected error
is mapped to EIO in the NFS stack. Out of curiosity, does qemu retry all
errors (ESTALE for example)? That's one example of an irrecoverable error.
From: Ayal Baron [mailto:aba...@redhat.com]
Sent: Sun 11/6/2011 1:19 AM
To: Labiaga, Ricardo
Cc: VDSM Project Development
During the workshop you asked about qemu behavior once resuming a VM after EIO.
I went back to check and qemu never passes the EIO to the guest, instead it
retries the I/O.
So it would seem that the current behavior should be fine (also with soft
Are there other error flows we should look into?
I seem to recall we discussed other issues as well, but I don't remember the
specifics (jet lag).
vdsm-devel mailing list