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

On Thu, Jul 14, 2011 at 7:47 PM, Adam Litke <agl(a)us.ibm.com&gt; 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.

>> 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.