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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Aug 16, 2024 at 11:23:01AM -0400, Peter Xu wrote:
> 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?

Conceptually "exec:" is a nice thing, but from a practical POV it
introduces difficulties for QEMU. QEMU doesn't know if the exec'd
command will provide a unidirectional channel or bidirectional
channel, so has to assume the worst - unidirectional. It also can't
know if it is safe to run the exec multiple times, or is only valid
to run it once - so afgai nhas to assume once only.

We could fix those by adding further flags in the migration address
to indicate if its bi-directional & multi-channel safe.

Technically "exec" is obsolete given "fd", but then that applies to
literally all protocols. Implementing them in QEMU is a more user
friendly thing.

Exec was more compelling when QEMU's other protocols were less
mature, lacking TLS for example, but I still find it interesting
as a facility.

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 :|