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

[Feng, Shaohe]

> -----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,

> >>>  Consider this scenario : one of the host/hypervisor are high cpu/memory usage,  
> >>>  Cloud Tool, such as Openstack can make a strategy that do not compression
> >>>  by multi-thread, for high cpu usage, they just want to use "xbzrle".
> >>>  
> >>>  Is this scenario reasonable? 

> >> +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