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

<<attachment: liyong_qiao.vcf>>

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

Reply via email to