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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]