On Fri, Aug 16, 2024 at 11:14:38AM -0400, Steven Sistare wrote: > On 8/16/2024 4:42 AM, Daniel P. Berrangé wrote: > > On Thu, Aug 15, 2024 at 04:28:59PM -0400, Peter Xu wrote: > > > On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Sistare wrote: > > > > > > The new user-visible interfaces are: > > > > > > * cpr-transfer (MigMode migration parameter) > > > > > > * cpr-uri (migration parameter) > > > > > > > > > > I wonder whether this parameter can be avoided already, maybe we can > > > > > let > > > > > cpr-transfer depend on unix socket in -incoming, then integrate fd > > > > > sharing > > > > > in the same channel? > > > > > > > > You saw the answer in another thread, but I repeat it here for others > > > > benefit: > > > > > > > > "CPR state cannot be sent over the normal migration channel, because > > > > devices > > > > and backends are created prior to reading the channel, so this mode > > > > sends > > > > CPR state over a second migration channel that is not visible to > > > > the user. > > > > New QEMU reads the second channel prior to creating devices or > > > > backends." > > > > > > Today when looking again, I wonder about the other way round: can we make > > > the new parameter called "-incoming-cpr", working exactly the same as > > > "cpr-uri" qemu cmdline, but then after cpr is loaded it'll be > > > automatically > > > be reused for migration incoming ports? > > > > > > After all, cpr needs to happen already with unix sockets. Having separate > > > cmdline options grants user to make the other one to be non-unix, but that > > > doesn't seem to buy us anything.. then it seems easier to always reuse it, > > > and restrict cpr-transfer to only work with unix sockets for incoming too? > > > > IMHO we should not be adding any new command line parameter at all, > > and in fact we should actually deprecate the existing "-incoming", > > except when used with "defer". > > > > An application managing migration should be doing all the configuration > > via QMP > > This is devilish hard to implement for cpr-uri, because it must be known > before any backends or devices are created. The existing preconfig phase > occurs too late. > > One must define a new precreate phase which occurs before any backends or > devices are created. Requires a new -precreate option and a precreate-exit > qmp command. > > Untangle catch-22 dependencies amongst properties, machine, and accelerator, > so that migration_object_init() can be called early, so that migration > commands are supported in the monitor. > > Extract monitor specific options and start a monitor (and first create > monitor chardevs, an exception to the "no creation" rule). > > If/when someone tackles the "all configuration via QMP" project, I would > be happy to advise, but right now a cpr-uri command-line parameter is > a sane and simple option.
So far it looks ok to me from migration POV, but that definitely sounds like relevant to whoever cares about this go-via-QMP-only project. Let me at least copy Paolo as I know he's in that, maybe anyone else too just to collect feedbacks, or just to let people know one more exception might be needed (if no NACK will come later). Thanks, -- Peter Xu
