Re: [RFC V1 0/6] Live update: cpr-transfer

[Steven Sistare]

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.

- Steve