vmm: migration: add user-configurable downtime and timeout - #7835

I understand it has been a legacy issue since --local was introduced, but with three new parameters it's reaching a point where it should be properly addressed.

I'd suggest: implement VmSendMigrationData::parse(cmd: &str) -> Result<Self> so that ch-remote passes a single comma-separated string rather than individual --flags.
The CLI would become:

$ ch-remote --api-socket=/tmp/api send-migration tcp:{dst}:{port},local=false,downtime_ms=300,timeout_s=60,timeout_strategy=cancel

instead of:

$ ch-remote --api-socket=/tmp/api send-migration tcp:{dst}:{port} --downtime-ms 300 --timeout-s 60 --timeout-strategy cancel

This keeps send-migration consistent with how the rest of ch-remote and cloud-hypervisor handle commandline options - using the option_parser comma-separated style. Having send-migration be the only subcommand using individual --flags creates an inconsistency for both users and contributors.

Beyond consistency, this would also:

• Eliminate the duplicated code from ch-remote;
• Use the exact data structure defined from vmm crate say (avoid defining a separate TimeoutStrategy enum in ch-remote);
• Make future parameter additions a one-line change instead of touching multiple call sites.

I understand this is a breaking change for --local, but I think now is the right time — before more parameters accumulate and the breaking change becomes harder to make.

While I agree that duplicate types are not ideal, I would argue that those types are only duplicates in name, not in function. User APIs and internal representation have different requirements and mixing both in a single type leads usability or type safety conflicts like the Duration one discussed above.

While the VmSendMigrationData::parse(cmd: &str) -> Result<Self> approach does separate these concerns, it skips some of the nice things clap already provides like the error messages.
Compare, for example, these two error messages caused by a trailing comma:

> cargo run --bin ch-remote -- --api-socket=/tmp/chv1.sock add-device path=foo,

[2026-03-17T08:06:12Z ERROR cloud_hypervisor] Fatal error: AddDeviceConfig(ParseDevice(UnknownOption("")))
Error: ch-remote exited with the following chain of errors:
  0: Error parsing device syntax
  1: Error parsing --device
  2: unknown option: 

> cargo run --bin ch-remote -- --api-socket=/tmp/chv1.sock send-migration tcp:127.0.0.1:1337 --downtime-ms 200,

error: invalid value '200,' for '--downtime-ms <downtime-ms>': invalid digit found in string

For more information, try '--help'.

From what I can see, VmSendMigrationData::parse(cmd: &str) -> Result<Self> also requires significant manual implementation.

I don't know the reasons for why this API style was chosen though, so it's very possible I'm missing important points.

I'm with @arctic-alpaca that clap's convenience is outstanding. That being said, I'm with you that we should stay consistent. We could refactor this in the future eventually.

Right. Let's fix the inconsistency issue here and follow-up on broader CLI changes in #7551.

I think the original terminology was more precise. Transport mechanism (TCP vs UNIX socket) is orthogonal to migration use cases ("remote" vs "local"), say:

• TCP to 127.0.0.1 is a local migration over TCP
• A UNIX socket forwarded by a management layer could serve a remote migration.

I'd suggest keeping the original naming.

thanks - changed that.

nit: I think this should probably be integrated into the previous commit since it breaks test bisect. I think it's fine to add new test in a later commit but adapting them (especially when the change is so simple) probably should be in the commit that changes it.

thanks, adressed!

nit: I feel like Ignore is the better terminology here? It's ignoring the timeout vs forcing some behaviour. But this would be an annoying change for you to make so I could live with it.

Na, no problem. Fixed it

There are hyphens here but underscores above?

good catch, fixed

Does receive-migration actually take a URL like this?

very good catch, thanks