[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] RFC New virDomainBlockPull API family to libvirt




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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]