[libvirt] [RFC] libvirt support multi-thread compression for live migration

[Qiao,Liyong]

On 2015年06月03日 01:02, Eric Blake wrote:
> On 06/02/2015 07:56 AM, Qiao, Liyong wrote:
>> Hi Eric
>> Thanks for replying the mail, replied in lines.
>>
>>> +virdomainMigrateGetParameters(virDomainPtr domain,
>>> +                                  int *level,
>>> +                                  int *threads,
>>> +                                  int *dthreads,
>>> +                                  int flags)
>>> +
>> I'd rather we used virTypedParameters, to make it easier to use the same API to pass ALL future possible tuning parameters, rather than just hard-coding to only the parameters of this one feature.
>>
>> Okay ,that sound good, but if virTypedParameters can be passed to qemu_driver such as qemu_monitor_json.c qemu_monitor_text.c ?
> [Your quoting style makes it very hard to distinguish original text from
> added text.  Please consider changing your outgoing mail process to
> ensure that you add another level of quoting to all previous text so
> that your added text is the only unquoted text.  Also, configure your
> mailer to wrap long lines.]
hi Eric, sorry about the inconvenient mail client, I switch outlook to 
thunder
bird, hopes it will be better.
> Use existing API for a guide - for example, virDomainSetBlockIoTune
> takes virTypedParamters, as well as defines a specific set of parameters
> that it will understand.  The set of parameters can be enlarged without
> needing a new API (good for backporting features without requiring a .so
> version bump), but for any given libvirt version, the set of features
> understood is finite and limited to what you can translate to the QMP
> call.  So qemu_driver.c would take the virTypedParameters, reject the
> ones it does not understand, and convert the ones it does understand
> into the 'int level, int threads, int dthreads' parameters used in
> qemu_monitor_json.c where you drive the actual QMP command with fixed
> parameters and types.
ah, that helps, thanks for kindly supporting, we will think a bit more 
to how
implement this API (taken virTypedParamters as parameter)
>
>
>> If we think that it is worth always turning on both compression styles simultaneously, then reuse the bit.  Otherwise, we need a different bit, and users can choose which (or both) of the two compression styles as desired.
>>
>> +1 for reuse compressed, and we can set compress-level, compress-threads, compress-dthreads by virdomainMigrateSetParameters(maybe some new virsh command--- migrate-setparameter)
>> But how can we passing these parameter when we using `virsh migrate `, is there any parameter we can use in 'virsh migrate' command ?
>> Can you point me out ?
> The underlying API already has a form that takes virTypedParameters (see
> virDomainMigrate3()), so your first task is to figure out how to extend
> the API to expose new typed parameters for your new migration tunings.
> Once that is done, then you can worry about how to tweak the 'virsh
> migrate' client to pass in those new parameters.
>
-- 
BR, Eli(Li Yong)Qiao

-------------- next part --------------
A non-text attachment was scrubbed...
Name: liyong_qiao.vcf
Type: text/x-vcard
Size: 123 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150603/3ed2ff20/attachment-0001.vcf>