Am 16.04.2012 09:17, schrieb Paolo Bonzini:
>>> + /*
>>> + * If reopening the image file we just created fails, fall back
>>> + * and try to re-open the original image. If that fails too, we
>>> + * are in serious trouble.
>>> + */
>>> + if (ret != 0) {
>>> + ret = bdrv_open(bs, old_filename, flags, old_drv);
>>> + if (ret != 0) {
>>> + error_set(errp, QERR_OPEN_FILE_FAILED, old_filename);
>>> + } else {
>>> + error_set(errp, QERR_OPEN_FILE_FAILED, new_image_file);
>>> + }
>>> + }
>>
>> In that worst-case scenario of failing to reopen the old file, should we
>> be halting the domain and/or propagating an event up to the user,
>> similar to how we behave on ENOSPC errors?
>
> Probably yes, but it's made more complex because the rerror/werror
> arguments are only known by the emulated device, not by the disk. I
> (and Federico before me) just copied the existing non-handling in live
> snapshots.
It happens more or less automatically. After a failed bdrv_open() you
have bs->drv = NULL, which makes any subsequent requests fail. This way
you trigger the rerror/werror paths indirectly.
Kevin
