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

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

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