Am 01.08.2012 13:17, schrieb Paolo Bonzini:
> 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).
Ah, yes, I misunderstood.
> 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?...
You don't? :-)
Maybe we should use named block devices from the beginning.
Kevin
