[libvirt] [PATCH V2] Set qemu migration speed unlimited when migrating to file

[Jim Fehlig]

Eric Blake wrote:
> On 08/04/2011 12:41 PM, Jim Fehlig wrote:
>>
>> Yeah, I debated about whether to even add this hunk, but was considering
>> 'virsh dump --live ...' where the  process still exists and could
>> potentially be migrated to another host later.
>
> Oh, I forgot about that.  I guess we do have a case where migration to
> file does not imply the death of the qemu process.
>
>>
>>>
>>> Meanwhile, it raises independent issues - why do we have a write-only
>>> interface in virDomainMigrateSetMaxSpeed?  Shouldn't we also be able
>>> to query the speed currently in use, and shouldn't the domain XML
>>> track the current migration speed?
>>
>> AFAICT, qemu doesn't provide a way to query the speed.  The monitor
>> would need this addition before we could plumb it in libvirt.
>
> Not necessarily true.  If we track it in the domain xml, then libvirt
> can update that xml any time it makes a change, and set qemu to match
> the xml any time that it is changed or qemu started, and answer
> queries from the xml rather than by querying the monitor.

Ah, right.  Good point.

>
>> How would you like to proceed?
>
> Are you in the mood to add virDomainMigrateGetMaxSpeed and the XML
> change necessary to track it?  If so, then I'd favor tackling that
> first, at which point we'll have answered our questions about what
> speed to restore here.

I don't have many free cycles ATM, but could add this to my todo list.

> I would even be okay with pushing this patch first (with the tweak of
> adding a #define for the 32<<20 magic number), if you can get more
> feedback from others agreeing on the points raised here; cleaning
> things up to restore the saved value rather than the default value
> would be an appropriate part of the series adding the ability to track
> the saved value.

Other opinions?  Is this patch useful as is (after fixing magic number)
or should Eric's suggestion of adding virDomainMigrateGetMaxSpeed() be
done first?  In most cases, the speed is changed when actually invoking
the virDomainMigrate* APIs, in which case the qemu process is terminated
after successful migration and the value is lost anyhow.  I guess the
only interesting case is apps that call virDomainMigrateSetMaxSpeed()
and expect the value to persist during life of associated qemu process.

Regards,
Jim