qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [RFC V1 0/6] Live update: cpr-transfer
Date: Fri, 16 Aug 2024 09:42:06 +0100
User-agent: Mutt/2.2.12 (2023-09-09)

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]