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(-)
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(-)
--
2.22.3
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
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
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
Het Gala <het.gala@nutanix.com> writes: > 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. > Hi, Is this the latest version of this series? I see errors with make check. Let me know if I should wait for your next version to comment.
On 05/09/23 6:52 pm, Fabiano Rosas wrote: > Het Gala <het.gala@nutanix.com> writes: > >> 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. >> > Hi, > > Is this the latest version of this series? I see errors with make > check. Let me know if I should wait for your next version to comment. This series was last posted in July end and make worked fine then. There might be changes with respect to migration workflow by now I suspect, that might be the reason for make check errors. Let me send a fresh new patchset version and will resolve make issues there. Thanks ! Regards, Het Gala
Het, On Mon, Aug 21, 2023 at 11:43:02AM +0530, Het Gala wrote: > 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. This all looks right to me from high level. I'd just trust Daniel's in depth review already, considering that Juan will probably give a final round of look soon, anyway. Juan was just busy in the past few weeks; I suppose he'll catch up very soon. Thanks, -- Peter Xu
© 2016 - 2024 Red Hat, Inc.