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

[Feng, Shaohe]

Eric, 
Thank you for reply.

Is it necessary to expose these two APIs to user application? 
+ virdomainMigrateSetCapabilities
+ virdomainMigrateGetCapabilities

For qemu , the migration capabilities are "xbzrle", "rdma-pin-all",  "auto-converge",
 "zero-blocks" and "compress".

Sorry , I use outlook. 
Will change to thunderbird. 
 
-----Original Message-----
From: Qiao, Liyong 
Sent: Wednesday, June 3, 2015 7:49 AM
To: Eric Blake; Feng, Shaohe; libvir-list at redhat.com
Cc: Bhandaru, Malini K; Ding, Jian-feng; Chylinski, Arek; Koniszewski, Pawel; Li, Liang Z; berrange at redhat.com; veillard at redhat.com
Subject: Re: [RFC] libvirt support multi-thread compression for live migration



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