----- 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;
   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      }
   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
  • EIO Ayal Baron
    • RE: EIO Labiaga, Ricardo
      • Re: EIO Ayal Baron

Reply via email to