On Tue, Apr 17, 2012 at 1:14 PM, Eric Blake wrote:
> On 04/17/2012 03:20 AM, Stefan Hajnoczi wrote:
>> 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 happen
On 04/17/2012 03:20 AM, Stefan Hajnoczi wrote:
> 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 t
On Tue, Apr 17, 2012 at 8:53 AM, Paolo Bonzini 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
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
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 actuall
