> -----Original Message----- > From: Qiao, Liyong > Sent: Wednesday, June 3, 2015 7:49 AM > To: Eric Blake; Feng, Shaohe; libvir-list@xxxxxxxxxx > Cc: Bhandaru, Malini K; Ding, Jian-feng; Chylinski, Arek; Koniszewski, Pawel; Li, > Liang Z; berrange@xxxxxxxxxx; veillard@xxxxxxxxxx > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list