On 04/19/2012 03:00 PM, Jiri Denemark wrote:
On Mon, Apr 16, 2012 at 23:06:03 -0600, Eric Blake wrote:
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(-)
OK
I'm hoping to actually drop this patch, and replace it with an alternative that calls set-block-job-speed _before_ block-stream or drive-mirror; but that depends on someone actually writing the qemu patch outlined in the thread here: https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg02273.html At any rate, this serves as a good argument for why the qemu side of this patch series isn't quite ready to push to upstream libvirt yet. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org