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

[Eric Blake]

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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120419/0f75cfe5/attachment-0001.sig>