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

On Mon, Jul 18, 2011 at 9:10 PM, Adam Litke <agl(a)us.ibm.com&gt; wrote: > 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; Working QEMU code is pushed to: http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/stream-command I am updating the QEMU wiki page with the latest changes.