[libvirt] RFC New virDomainBlockPull API family to libvirt

[Adam Litke]

On 07/15/2011 05:39 AM, Stefan Hajnoczi wrote:
> On Thu, Jul 14, 2011 at 7:47 PM, Adam Litke <agl at us.ibm.com> wrote:
>> On 07/13/2011 08:04 PM, Daniel Veillard wrote:
>>> On Wed, Jul 13, 2011 at 03:46:30PM -0500, Adam Litke wrote:
>>>> Unfortunately, after committing the blockPull API to libvirt, the qemu
>>>> community decided to change the API somewhat and we needed to revert the
>>>> libvirt implementation.  Now that the qemu API is settling out again, I would
>>>> like to propose an updated libvirt public API which has required only a minor
>>>> set of changes to sync back up to the qemu API.
>>>>
>>>> Summary of changes:
>>>>  - Qemu dropped incremental streaming so remove libvirt incremental
>>>>    BlockPull() API
>>>>  - Rename virDomainBlockPullAll() to virDomainBlockPull()
>>>>  - Changes required to qemu monitor handlers for changed command names
>>>
>>>
>>>   Okay.

<snip>

>>>   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() ?



-- 
Adam Litke
IBM Linux Technology Center