[libvirt] [RFC] libvirt support multi-thread compression for live migration
Feng, Shaohe
shaohe.feng at intel.com
Wed Jun 3 15:13:17 UTC 2015
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
More information about the libvir-list
mailing list