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