Re: [Qemu-devel] block-stream/drive-mirror and default bandwidth

[Stefan Hajnoczi]

On Tue, Apr 17, 2012 at 8:53 AM, Paolo Bonzini <address@hidden> wrote:
> Il 17/04/2012 04:50, Eric Blake ha scritto:
>> Libvirt found out that we have a pretty nasty data race between
>> block-stream and block-job-set-speed.  If a user wants to throttle a
>> job, they cannot request the throttling until after the job has been
>> started (thanks to the DeviceNotActive error of block-job-set-speed),
>> but by the time you actually get a chance to throttle the job, you have
>> no idea how much data transpired between the job start and the
>> throttling request.  migrate_set_speed does not have this issue, since
>> it can be issued _prior_ to the migration.
>>
>> Is there any way we can add an optional parameter to 'block-stream' (in
>> the tree now) and 'drive-mirror' (in Paolo's pending patch series) to
>> set the speed as part of starting the job, or to atomically fail with
>> NotSupported if throttling cannot be managed, rather than having a race
>> window before getting a chance to call block-job-set-speed?  Now's the
>> time to do it, since 'block-stream' is new to qemu 1.1.
>
> The NotSupported error from block-job-set-speed is really an
> out-of-range error, and we should report it as such...
>
> I think that rather than adding lots of arguments, two better choices
> are: 1) cancel the job if set-speed fails (for some definition of
> better); 2) let block-job-set-speed work before starting a job, like you
> said migration does.

I think it's cleanest to support block-job-set-speed even when no job
is running.  The speed will be used as the default value when a job is
started.  This poses the question of what happens if the job does not
do throttling or cannot support the value for some reason - does
creation fail until block-job-set-speed is set to 0 or a valid value
again, or do we allow it but silently perform no throttling?

Stefan