Il 01/08/2012 12:14, Kevin Wolf ha scritto:
>> > Signed-off-by: Paolo Bonzini <[email protected]>
> If we want to switch to named target block devices later, it would
> probably make sense to use the io_status of that block device rather
> than adding it to the job.
>
> Maybe what results is a duplication that can be tolerated, though.
We are probably thinking of two opposite implementations.
You are thinking:
- errors in streaming, or in the mirroring source go to the block device
- errors in the mirroring target go to the block job
What I implemented is:
- errors in streaming, or in the mirroring source go to the block job
- errors in the mirroring target go to the target block device (which as
of this series could be inspected with query-block-jobs).
The reason is that an error in streaming or in the mirroring source does
not stop the VM. A hypothetical management that polled for errors with
"info block" would see a mismatch between the error state ("failed") and
the VM RunState ("running").
So this is already ready for making the target block device visible.
The real question is: if I remove the possibility to inspect the (so far
anonymous) target device with query-block-jobs, how do you read the
status of the target device?...
Paolo
>> + }
>> + bdrv_emit_qmp_error_event(job->bs, QEVENT_BLOCK_JOB_ERROR, action,
>> is_read);
>> + if (action == BDRV_ACTION_STOP) {
>> + block_job_pause(job);
>> + if (bs == job->bs) {
>> + block_job_iostatus_set_err(job, error);
>> + } else {
>> + bdrv_iostatus_set_err(bs, error);
>> + }
>
> However, so that everything just falls into place once we make the
> target block device visible, I'd make the bdrv_iostatus_set_err() call
> unconditional then.
Paolo
