On 26/12/22 11:03 am, Het Gala wrote:
Current QAPI 'migrate' command design (for initiating a migration
stream) contains information regarding different migrate transport mechanism
(tcp / unix / exec), dest-host IP address, and binding port number in form of
a string. Thus the design does seem to have some design issues. Some of the
issues, stated below are:
1. Use of string URIs is a data encoding scheme within a data encoding scheme.
QEMU code should directly be able to work with the results from QAPI,
without resorting to do a second level of parsing (eg. socket_parse()).
2. For features / parameters related to migration, the migration tunables needs
to be defined and updated upfront. For example, 'migrate-set-capability'
and 'migrate-set-parameter' is required to enable multifd capability and
multifd-number of channels respectively. Instead, 'Multifd-channels' can
directly be represented as a single additional parameter to 'migrate'
QAPI. 'migrate-set-capability' and 'migrate-set-parameter' commands could
be used for runtime tunables that need setting after migration has already
started.
The current patchset focuses on solving the first problem of multi-level
encoding of URIs. The patch defines 'migrate' command as a QAPI discriminated
union for the various transport backends (like socket, exec and rdma), and on
basis of transport backends, different migration parameters are defined.
(uri) string --> (channel) Channel-type
Transport-type
Migration parameters based on transport type
I hope all of you had nice a lovely christmas :) and wish you all a
beautiful new year!!
Just a gentle reminder for patch review.
This patchset series focuses on the idea of modifying qemu 'migration'
QAPI syntax into a well defined data structure.
Hoping for suggestions and active discussions on the patchset series
from all the maintainers.
Regards,
Het Gala
