On Fri, Apr 11, 2025 at 04:14:30PM -0300, Fabiano Rosas wrote: > Open questions: > --------------- > > - Deprecations/compat? > > I think we should deprecate migrate-set/query-capabilities and everything to > do > with capabilities (specifically the validation in the JSON at the end of the > stream). > > For migrate-set/query-parameters, we could probably keep it around > indefinitely, > but it'd be convenient to introduce new commands so we can give them new > semantics. > > - How to restrict the options that should not be set when the migration is in > progress? > > i.e.: > all options can be set before migration (initial config) > some options can be set during migration (runtime) > > I thought of adding another type at the top of the hierarchy, with > just the options allowed to change at runtime, but that doesn't really > stop the others being also set at runtime. I'd need a way to have a > set of options that are rejected 'if migration_is_running()', without > adding more duplication all around. > > - What about savevm? > > None of this solves the issue of random caps/params being set before > calling savevm. We still need to special-case savevm and reject > everything. Unless we entirely deprecate setting initial options via > set-parameters (or set-config) and require all options to be set as > savevm (and migrate) arguments.
I'd suggest we aim for a world where the commands take all options as direct args and try to remove the global state eventually. For savevm/loadvm in particular it is very much a foot-gun that 'migrate-set-*' will affect them, because savevm/loadvm aren't obviously connected to 'migrate-*' commands unless you're aware of how QEMU implements savevm internally. > - HMP? > > Can we convert the strings passed via hmp_set_parameters without > having an enum of parameters? Duplication problem again. > > - incoming defer? > > It seems we cannot do the final step of removing > migrate-set-capabilites before we have a form of handshake > implemented. That would take the config from qmp_migrate on source and > send it to the destination for negotiation. I'm not sure I understand why the QAPI design changes are tied to the new protocol handshake ? I guess you're wanting to avoid updating 'migrate_incoming' to accept the new parameters directly ? 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 :|
