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

[Peter Xu]

On Fri, Aug 16, 2024 at 11:13:36AM -0400, Steven Sistare wrote:
> On 8/15/2024 4:28 PM, 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?
> 
> This idea also occurred to me, but I dislike the loss of flexibility for
> the incoming socket type.  The exec URI in particular can do anything, and
> we would be eliminating it.

Ah, I would be guessing that if Juan is still around then exec URI should
already been marked deprecated and prone to removal soon.. while I tend to
agree that exec does introduce some complexity meanwhile iiuc nobody uses
that in production systems.

What's the exec use case you're picturing?  Would that mostly for debugging
purpose, and would that be easily replaceable with another tunnelling like
"ncat" or so?

> 
> I also think -incoming-cpr has equal or greater "specification complexity" 
> than
> -cpr-uri.  They both add a new option, and the former also modifies the 
> behavior
> of an existing option (disallows it and subsumes it).

Please see Dan's comment elsewhere.  I wonder whether we can do it without
new qemu cmdlines if that's what we're looking for for the long term.  If
QMP is accessbile before cpr early loads, then we can set cpr mode and
reuse migrate-incoming with no new parameter added.

-- 
Peter Xu