On 11/19/2024 4:29 PM, Peter Xu wrote:
On Tue, Nov 19, 2024 at 04:03:08PM -0500, Steven Sistare wrote:
On 11/19/2024 3:51 PM, Peter Xu wrote:
On Tue, Nov 19, 2024 at 03:32:55PM -0500, Steven Sistare wrote:
This begs the question, should we allow channels to be specified in hmp migrate
commands and for -incoming, in a very simple way? Like with a prefix naming
the channel. And eliminate the -cpr-uri argument. Examples:
(qemu) migrate -d main:tcp:0:44444,cpr:unix:cpr.sock
qemu -incoming main:tcp:0:44444,cpr:unix:cpr.sock
qemu -incoming main:defer,cpr:unix:cpr.sock
IMHO keeping the old syntax working would still be nice to not break
scripts.
The channel tag would be optional, so backwards compatible. Its unambiguous
as long as the channel names are not also protocol names.
Ah that's ok then. Or maybe use "="?
"main=XXX,cpr=XXX"
Then if no "=" it's the old?
Sure, that works.
I was thinking we could simply add one more parameter for taking
cpr uri, like:
{
.name = "migrate",
.args_type = "detach:-d,resume:-r,uri:s,cpr:s?",
.params = "[-d] [-r] uri [cpr_uri]",
.help = "migrate to URI (using -d to not wait for completion)"
"\n\t\t\t -r to resume a paused postcopy migration",
"\n\t\t\t Setup cpr_uri to migrate with cpr-transfer",
.cmd = hmp_migrate,
},
That's fine.
I do like the incoming syntax, though, instead of -cpr-uri. What do you think?
That'll definitely be lovely if possible, though would any monitor be alive
at all before taking a cpr stream, with this series alone? I thought you
dropped the precreate, then QEMU isn't able to run the monitor loop until
cpr-uri is loaded.
No monitor or precreate changes. I would parse -incoming, extract and use the
cpr
channel early, and use the main channel later as usual. It's just a different
way of
specifying cpr-uri. I like it because the specification language is more
consistent,
referring to a "cpr channel" both on the outgoing and incoming side:
This mode requires a second migration channel named "cpr", included in
the channel arguments of the migrate command on the outgoing side, and
in the QEMU -incoming parameter on the incoming side. The channel must
be a type, such as unix socket, that supports SCM_RIGHTS.
- Steve
