On 07/18/2011 09:35 AM, Stefan Hajnoczi wrote:
>>>>> On the other hand I suspect that we are missing the mechanism to
>>>>> control the rate of the transfer in the new API, which is something
>>>>> which could be implemented in the old incremental mechanism, but not
>>>>> anymore. So I wonder if the virDomainBlockPull() shouldn't get an
>>>>> "unsigned long bandwidth" (to stay coherent with migration APIs)
>>>>> before the flags. I don't know if the support is ready in QEmu but
>>>>> I suspect that will be an important point, so if not present will
>>>>> be added :-)
>>>>
>>>> Hopefully Stefan can comment on any throttling mechanisms that might be
>>>> added to the qemu implementation. It would be nice to have this feature
>>>> built into the API to match the migration APIs, but if that is not
>>>> feasible then we could always add it later.
>>>
>>> If we follow the live migration API then a block_stream_set_speed
>>> command would be used. libvirt would issue it as a separate command
>>> immediately after starting the streaming operation. There is the
>>> window of time after streaming has started but before
>>> block_stream_set_speed has been called where no throttling takes
>>> place, but I don't think this is a practical problem.
>>>
>>> It also opens the possibility of allowing the user to change the rate
>>> limit value while the block streaming operation is active.
>>
>> In light of our decision to provide a generic BlockJobAbort/BlockJobInfo
>> interface, should SetSpeed be generic too?
>>
>> virDomainBlockJobSetSpeed() or virDomainBlockPullSetSpeed() ?
>
> The block_stream_set_speed semantics allow the command to be used when
> no streaming operation is active. This can be used to set the speed
> without a window of time after creation and before set_speed is
> called.
>
> If we switch to block_job_set_speed then it is cleaner to restrict the
> command to work on active jobs only. This is because there is only
> one "speed" variable kept but there might be multiple job types
> (streaming, compaction, etc) which would need different settings.
>
> What do you think about this?
I think the block_job_set_speed semantics seem reasonable to me. What is
the method for querying the current speed setting? I would suggest
extending the query-block-job command to include this information. In
this case, I would extend virDomainBlockJobInfo to contain:
/* The maximum allowable bandwidth for this job (MB/s) */
unsigned long bandwidth;
>
> block_job_set_speed
> -------------------
>
> Set maximum speed for a background block operation.
>
> This is a per-block device command that can only be issued
> when there is an active block job.
>
> Throttling can be disabled by setting the speed to 0.
>
> Arguments:
>
> - device: device name (json-string)
> - value: maximum speed, in bytes per second (json-int)
>
> Errors:
> NotSupported: job type does not support speed setting
>
> Example:
>
> -> { "execute": "block_job_set_speed",
> "arguments": { "device": "virtio0", "value": 1024 } }
>
> Stefan
>
--
Adam Litke
IBM Linux Technology Center
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list