----- 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:aba...@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 mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
