Hi Ricardo,
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 mounts).
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).
Regards, Ayal.
Hi Ayal,
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.
- ricardo
-----Original Message----- From: Ayal Baron [mailto:abaron@redhat.com] Sent: Sun 11/6/2011 1:19 AM To: Labiaga, Ricardo Cc: VDSM Project Development Subject: EIO
Hi Ricardo,
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 mounts).
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).
Regards, Ayal.
----- Original Message -----
Hi Ayal,
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.
We have discussed automatically resuming the VM and retrying every few seconds but the jury is out on whether this is a good idea or not. Any recommendations on that?
wrt different error handling according to specific error, I am not aware of any such code in qemu. I would suggest raising this issue on qemu-devel. Note that if the image itself is stale then I think that the only course of action is to shutdown the VM (unless user has a way to fix this? in which case current behavior is fine).
What I know about is: qemu block.c:
1517 /* RHEL6 vendor extension */ 1518 static void bdrv_put_rhel6_reason(QDict *event, int error) 1519 { 1520 const char *reason; 1521 1522 switch (error) { 1523 case ENOSPC: 1524 reason = "enospc"; 1525 break; 1526 case EPERM: 1527 reason = "eperm"; 1528 break; 1529 case EIO: 1530 reason = "eio"; 1531 break; 1532 default: 1533 reason = "eother"; 1534 break; 1535 } 1536 1537 qdict_put(event, BDRV_REASON_KEY, qstring_from_str(reason)); 1538 }
- ricardo
-----Original Message----- From: Ayal Baron [ mailto:abaron@redhat.com ] Sent: Sun 11/6/2011 1:19 AM To: Labiaga, Ricardo Cc: VDSM Project Development Subject: EIO
Hi Ricardo,
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 mounts).
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).
Regards, Ayal.
vdsm-devel@lists.fedorahosted.org