On 02/01/23 12:48 pm, Het Gala wrote:
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.
A gentle reminder once again :)
This patchset could prove to the base of changing wire protocol around
migration QAPIs. It could help in taking other decisions regarding
restructuring around live migration code base in future.
Would be glad to have some feedback on the patches from the maintainers.
Waiting for a positive response from the upstream community.
Regards, Het Gala
