Re: [libvirt] [PATCHv5 12/23] blockjob: relax block job behavior when setting speed up front

In qemu, it is possible to call 'migrate_set_speed' prior to 'migrate', and therefore ensure a constant throttling through the entire migration. However, this is not possible with 'block-job-set-speed', which fails if a job is not already active. This means that you can't detect a device that doesn't support throttling until after you have already started a block job and let an unknown amount of unthrottled data through. Aborting the job upon failure to set the speed seems a bit harsh, since it would have been nicer to prevent the job from starting in the first place, rather than letting an unknown amount of data be processed before detecting the speed failure. So I propose relaxing the documentation, and explicitly mentioning that setting the speed is a best-effort attempt that might be ignored. On the other hand, I've also requested that qemu consider adding an optional parameter to allow setting the speed at the creation of a block job. * src/libvirt.c (virDomainBlockPull, virDomainBlockRebase): Update the documentation. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl) (qemuDomainBlockCopy): Log but don't fail when speed change fails. --- v5: new patch; see also this qemu request: https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg02185.html src/libvirt.c | 12 ++++++++++-- src/qemu/qemu_driver.c | 18 ++++++++++++------ 2 files changed, 22 insertions(+), 8 deletions(-)