From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Het Gala <het.gala@nutanix.com>
Cc: qemu-devel@nongnu.org, prerna.saxena@nutanix.com,
quintela@redhat.com, dgilbert@redhat.com, pbonzini@redhat.com,
armbru@redhat.com, eblake@redhat.com, manish.mishra@nutanix.com,
aravind.retnakaran@nutanix.com
Subject: Re: [PATCH v2 2/6] migration: Updated QAPI format for 'migrate' qemu monitor command
Date: Thu, 9 Feb 2023 10:29:59 +0000 [thread overview]
Message-ID: <Y+TLJ9Ui790bIR3b@redhat.com> (raw)
In-Reply-To: <20230208093600.242665-3-het.gala@nutanix.com>
On Wed, Feb 08, 2023 at 09:35:56AM +0000, Het Gala wrote:
> Existing 'migrate' QAPI design enforces transport mechanism, ip address
> of destination interface and corresponding port number in the form
> of a unified string 'uri' parameter for initiating a migration stream.
> This scheme has a significant flaw in it - double encoding of existing
> URIs to extract migration info.
>
> The current patch maps QAPI uri design onto well defined MigrateChannel
> struct. This modified QAPI helps in preventing multi-level uri
> encodings ('uri' parameter is kept for backward compatibility).
>
> Suggested-by: Daniel P. Berrange <berrange@redhat.com>
> Suggested-by: Manish Mishra <manish.mishra@nutanix.com>
> Suggested-by: Aravind Retnakaran <aravind.retnakaran@nutanix.com>
> Signed-off-by: Het Gala <het.gala@nutanix.com>
> ---
> qapi/migration.json | 131 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 129 insertions(+), 2 deletions(-)
>
> diff --git a/qapi/migration.json b/qapi/migration.json
> index c84fa10e86..79acfcfe4e 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -1449,12 +1449,108 @@
> ##
> { 'command': 'migrate-continue', 'data': {'state': 'MigrationStatus'} }
>
> +##
> +# @MigrateTransport:
> +#
> +# The supported communication transport mechanisms for migration
> +#
> +# @socket: Supported communication type between two devices for migration.
> +# Socket is able to cover all of 'tcp', 'unix', 'vsock' and
> +# 'fd' already
> +#
> +# @exec: Supported communication type to redirect migration stream into file.
> +#
> +# @rdma: Supported communication type to redirect rdma type migration stream.
> +#
> +# Since 8.0
> +##
> +{ 'enum': 'MigrateTransport',
> + 'data': ['socket', 'exec', 'rdma'] }
> +
> +##
> +# @MigrateSocketAddr:
> +#
> +# To support different type of socket.
> +#
> +# @socket-type: Different type of socket connections.
> +#
> +# Since 8.0
> +##
> +{ 'struct': 'MigrateSocketAddr',
> + 'data': {'socket-type': 'SocketAddress' } }
I'd really like this struct to go away, but if it must exist,
then call this field 'addr', as I think 'socket-type' is overly
verbose.
> +
> +##
> +# @MigrateExecAddr:
> + #
> + # Since 8.0
> + ##
> +{ 'struct': 'MigrateExecAddr',
> + 'data' : {'data': ['str'] } }
Instead of having the field called 'data' lets me more
descriptive, and perhaps rename the struct too:
{ 'struct': 'MigrateCommand',
'data' : {'args': ['str'] } }
Any thoughts on whether we should allow for setting env varibles
too ?
> +##
> +# @MigrateRdmaAddr:
> +#
> +# Since 8.0
> +##
> +{ 'struct': 'MigrateRdmaAddr',
> + 'data' : {'data': 'InetSocketAddress' } }
InetSocketAddress is a plain struct, so I think we can use
that directly, no ?
> +
> +##
> +# @MigrateAddress:
> +#
> +# The options available for communication transport mechanisms for migration
> +#
> +# Since 8.0
> +##
> +{ 'union' : 'MigrateAddress',
> + 'base' : { 'transport' : 'MigrateTransport'},
> + 'discriminator' : 'transport',
> + 'data' : {
> + 'socket' : 'MigrateSocketAddr',
> + 'exec' : 'MigrateExecAddr',
> + 'rdma': 'MigrateRdmaAddr' } }
Ideally this would be
'data' : {
'socket' : 'SocketAddress',
'exec' : 'MigrateCommand',
'rdma': 'InetSocketAddress' } }
though the first SocketAddress isn't possible unless it is easy to
lift the QAPI limitation.
> ##
> # @migrate:
> #
> # Migrates the current running guest to another Virtual Machine.
> #
> # @uri: the Uniform Resource Identifier of the destination VM
> +# for migration thread
> +#
> +# @channel: Struct containing migration channel type, along with all
> +# the details of destination interface required for initiating
> +# a migration stream.
> #
> # @blk: do block migration (full disk copy)
> #
> @@ -1479,15 +1575,46 @@
> # 3. The user Monitor's "detach" argument is invalid in QMP and should not
> # be used
> #
> +# 4. The uri argument should have the Uniform Resource Identifier of default
> +# destination VM. This connection will be bound to default network
> +#
> +# 5. Both 'uri' and 'channel' arguments, are mutually exclusive but, at least
> +# one of the two arguments should be present.
> +#
> # Example:
> #
> # -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } }
> # <- { "return": {} }
> #
> +# -> { "execute": "migrate",
> +# "arguments": {
> +# "channel": { "channeltype": "main",
> +# "addr": { "transport": "socket",
> +# "socket-type": { "type': "inet',
> +# "host": "10.12.34.9",
> +# "port": "1050" } } } } }
> +# <- { "return": {} }
> +#
> +# -> { "execute": "migrate",
> +# "arguments": {
> +# "channel": { "channeltype": "main",
> +# "addr": { "transport": "exec",
> +# "exec": ["/bin/nc", "-U",
> +# "/some/sock" ] } } } }
> +# <- { "return": {} }
> +#
> +# -> { "execute": "migrate",
> +# "arguments": {
> +# "channel": { "channeltype": "main",
> +# "addr": { "transport": "rdma",
> +# "rdma": { "host": "10.12.34.9",
> +# "port": "1050" } } } } }
> +# <- { "return": {} }
> +#
> ##
> { 'command': 'migrate',
> - 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool',
> - '*detach': 'bool', '*resume': 'bool' } }
> + 'data': {'*uri': 'str', '*channel': 'MigrateChannel', '*blk': 'bool',
> + '*inc': 'bool', '*detach': 'bool', '*resume': 'bool' } }
IIRC, the intention was to allow multiple channels to be set in a
follow up to this series. If so that would require adding yet another
field as an array of MigrateChannel. Should we just go for the
array straight away, and just limit it to 1 element as a runtime
check ? eg
'data': {'*uri': 'str', '*channels': ['MigrateChannel'], '*blk': 'bool',
'*inc': 'bool', '*detach': 'bool', '*resume': 'bool' } }
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-02-09 10:31 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 9:35 [PATCH v2 0/6] migration: Modified 'migrate' QAPI command for migration Het Gala
2023-02-08 9:35 ` [PATCH v2 1/6] migration: moved hmp_split_at_commma() helper func to qapi-util.c file Het Gala
2023-02-09 12:00 ` Markus Armbruster
2023-02-09 12:12 ` Juan Quintela
2023-02-09 13:58 ` Het Gala
2023-02-09 16:19 ` Markus Armbruster
2023-02-09 13:28 ` Het Gala
2023-02-09 12:02 ` Daniel P. Berrangé
2023-02-09 13:30 ` Het Gala
2023-02-08 9:35 ` [PATCH v2 2/6] migration: Updated QAPI format for 'migrate' qemu monitor command Het Gala
2023-02-08 20:17 ` Eric Blake
2023-02-09 7:57 ` Het Gala
2023-02-09 10:23 ` Daniel P. Berrangé
2023-02-09 13:00 ` Het Gala
2023-02-09 13:38 ` Daniel P. Berrangé
2023-02-10 6:37 ` Het Gala
2023-02-10 10:31 ` Markus Armbruster
2023-02-09 16:26 ` Markus Armbruster
2023-02-10 6:15 ` Het Gala
2023-02-09 10:29 ` Daniel P. Berrangé [this message]
2023-02-09 13:11 ` Het Gala
2023-02-09 13:22 ` Daniel P. Berrangé
2023-02-10 8:24 ` Het Gala
2023-02-10 7:24 ` QAPI unions as branches / unifying struct and union types (was: [PATCH v2 2/6] migration: Updated QAPI format for 'migrate' qemu monitor command) Markus Armbruster
2023-02-10 13:28 ` Het Gala
2023-02-14 10:16 ` QAPI unions as branches / unifying struct and union types Markus Armbruster
2023-02-17 11:18 ` Het Gala
2023-02-17 11:55 ` Daniel P. Berrangé
2023-02-21 9:17 ` Het Gala
2023-02-08 9:35 ` [PATCH v2 3/6] migration: HMP side changes for modified 'migrate' QAPI design Het Gala
2023-02-09 12:05 ` Daniel P. Berrangé
2023-02-09 13:38 ` Het Gala
2023-02-09 14:00 ` Daniel P. Berrangé
2023-02-10 6:44 ` Het Gala
2023-02-08 9:35 ` [PATCH v2 4/6] migration: Avoid multiple parsing of uri in migration code flow Het Gala
2023-02-09 10:40 ` Daniel P. Berrangé
2023-02-09 13:21 ` Het Gala
2023-02-09 12:09 ` Daniel P. Berrangé
2023-02-09 13:54 ` Het Gala
2023-02-09 14:06 ` Daniel P. Berrangé
2023-02-10 7:03 ` Het Gala
2023-02-08 9:35 ` [PATCH v2 5/6] migration: Modified 'migrate-incoming' QAPI and HMP side changes on the destination interface Het Gala
2023-02-08 20:19 ` Eric Blake
2023-02-09 7:59 ` Het Gala
2023-02-09 10:31 ` Daniel P. Berrangé
2023-02-09 13:14 ` Het Gala
2023-02-09 13:25 ` Daniel P. Berrangé
2023-02-08 9:36 ` [PATCH v2 6/6] migration: Established connection for listener sockets on the dest interface Het Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y+TLJ9Ui790bIR3b@redhat.com \
--to=berrange@redhat.com \
--cc=aravind.retnakaran@nutanix.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=het.gala@nutanix.com \
--cc=manish.mishra@nutanix.com \
--cc=pbonzini@redhat.com \
--cc=prerna.saxena@nutanix.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.