On 05/04/2010 03:30 PM, Luiz Capitulino wrote:
StateVmSaveFailed is not like CommandFailed, there are five errors
in do_savevm() and StateVmSaveFailed happens to be one of them.
But I understand what you mean and I have considered doing something
like it, one of the problems though is that I'm not sure 'source' is
enough to determine where the error has happened.
Consider do_savevm() again. We have three 'operations' that might
fail: delete an existing snapshot, save the VM state and create the
snapshot. All those operations can return -EIO as an error.
Maybe those three operations should return distinct errnos?
That way, we can make more useful QErrors.
So, the first question is: would you map EIO to an QError? Just like
you did for SocketIOError? If so, how would you know which operation
has failed? Would you put its name in source? Or have an additional
'operation' key?
A related problem is not to degrade the current set of error messages
we offer to the users. For do_savevm()'s 'save state' operation, current
message is:
"Error -7 while writing VM"
With StateVmSaveFailed it becomes:
"Failed to save VM state ("EIO")"
I don't think this is that useful to preserve because as you said, it
could be one of three things.
Regards,
Anthony Liguori
Given the current implementation of QError, I'm not sure how we can have
such a good error message if our QErrors are not 'operation based'.
