Hi qemu-devel community,
A gentle reminder and request for all migration maintainers - Peter,
Juan, Dr. Gilbert and others too for review of the patchset series.
Received reviewed-by from Daniel on migration implementation patches but
need final approval from migration maintainers before getting it merged.
Also got acked-by tag from Markus on the QAPI patches. This is Part1 of
the 4 patchset series. Ultimate goal of the whole 4 series is to
'introduce multiple interface support on top of existing multifd
capability'. Hope to get approval or comments from migration maintainers
on the patches soon.
Thankyou :)
On 03/08/23 11:13 am, Het Gala wrote:
Hi,
A gentle reminder for Juan and other migration maintainers for the
review of this patchset series if any changes are required or give to
queue them. There are more patchset series coming after this. As
discussed earlier, we have broken down it into 4 different patchset
series. This is just Part1 of the 4 patchset series. Ultimate goal is
to 'introduce multiple interface support on top of existing multifd
capability'.
On 27/07/23 4:59 pm, Het Gala wrote:
This is just a ping for Juan and other migration maintainers, if it's
possible to have a look at the migration patches for new QAPI design
and suggest some review comments if any.
Update till now : Have got acked-by label from Markus for the new
migrate QAPI design, and reviewd-by label from Daniel on the QAPI
implementation side patches.
On 26/07/23 7:48 pm, Het Gala wrote:
This is v10 patchset of modified 'migrate' and 'migrate-incoming'
QAPI design
for upstream review.
Would like to thank all the maintainers that actively participated
in the v9
patchset discussion and gave insightful suggestions to improve the
patches.
Link to previous upstream community patchset links:
v1: https://lists.gnu.org/archive/html/qemu-devel/2022-12/msg04339.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg02106.html
v3: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg02473.html
v4: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg03064.html
v5: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg04845.html
v6: https://lists.gnu.org/archive/html/qemu-devel/2023-06/msg01251.html
v7: https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02027.html
v8: https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02770.html
v9: https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg04216.html
v9 -> v10 changelog:
-------------------
- Patch6 : Added extra checks for migration arguments.
- Patch8 : Added checks for 'uri' and 'channels' both not present.
- Patch9 : Missed adding hmp_handle_error call to print error messages.
Abstract:
---------
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
------------------------------------------------------------------------------
Het Gala (10):
migration: New QAPI type 'MigrateAddress'
migration: convert migration 'uri' into 'MigrateAddress'
migration: convert socket backend to accept MigrateAddress
migration: convert rdma backend to accept MigrateAddress
migration: convert exec backend to accept MigrateAddress.
migration: New migrate and migrate-incoming argument 'channels'
migration: modify migration_channels_and_uri_compatible() for new
QAPI
syntax
migration: Implement MigrateChannelList to qmp migration flow.
migration: Implement MigrateChannelList to hmp migration flow.
migration: modify test_multifd_tcp_none() to use new QAPI syntax.
migration/exec.c | 72 +++++++++----
migration/exec.h | 8 +-
migration/migration-hmp-cmds.c | 17 ++-
migration/migration.c | 190
++++++++++++++++++++++++++-------
migration/migration.h | 3 +-
migration/rdma.c | 34 +++---
migration/rdma.h | 6 +-
migration/socket.c | 39 ++-----
migration/socket.h | 7 +-
qapi/migration.json | 150 +++++++++++++++++++++++++-
softmmu/vl.c | 2 +-
tests/qtest/migration-test.c | 7 +-
12 files changed, 409 insertions(+), 126 deletions(-)
Regards,
Het Gala
Regards,
Het Gala
Regards,
Het Gala
