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;