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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 604 bytes)