[libvirt] [RFC] libvirt support multi-thread compression for live migration
Jiri Denemark
jdenemar at redhat.com
Wed Jun 10 13:15:48 UTC 2015
On Fri, Jun 05, 2015 at 08:22:31 +0800, Qiao,Liyong wrote:
>
>
> On 2015年06月04日 20:09, Jiri Denemark wrote:
> > On Tue, Jun 02, 2015 at 11:02:27 -0600, 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.]
> >>
> >> Use existing API for a guide - for example, virDomainSetBlockIoTune
> >> takes virTypedParamters, as well as defines a specific set of parameters
> >> that it will understand.
> > And do we actually need to changed these migration parameters on the fly
> > when migration is already running. I can imagine we would need to do so
> > for some parameters but multithreaded compression sounds like something
> > that needs to be configured when migration starts and there's nothing to
> > be tuned on the fly. If this is the case, I think we should just add
> > these new parameters to virDomainMigrate3 instead of requiring another
> > API to be called to actually configure multithreaded compression.
> >
> > The separate API makes it a bit harder to repeat migration (which
> > previously failed) with a different parameters (e.g., without
> > multithreaded compression).
> hi jirka
> thanks for your advice, that make sense for me.
>
> if I understanding you correctly,
> then we need only do this
>
> virsh migrate --live --compressed --compress-level 1--compress-threads 8
> --decompress-threads 2
>
> and all compressed parameters (compress-level ,compress-threads,
> decompress-threads) only
> be specified when we do call virDomainMigrate3 instead of expose to user
> by 'virsh migrate-setparameters' ?
Right, although there still seems to be an open question whether we can
reuse --compressed or we need to come up with another option so that we
can independently turn on XBZRLE and multithreaded compression.
Jirka
More information about the libvir-list
mailing list