From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dave@treblig.org>,
"Lukas Straub" <lukasstraub2@web.de>,
qemu-devel@nongnu.org, "Juraj Marcin" <jmarcin@redhat.com>,
"Fabiano Rosas" <farosas@suse.de>,
"Markus Armbruster" <armbru@redhat.com>,
"Lukáš Doktor" <ldoktor@redhat.com>,
"Juan Quintela" <quintela@trasno.org>,
"Zhang Chen" <zhangckid@gmail.com>,
zhanghailiang@xfusion.com, "Li Zhijian" <lizhijian@fujitsu.com>,
"Jason Wang" <jasowang@redhat.com>
Subject: Re: [PATCH 1/3] migration/colo: Deprecate COLO migration framework
Date: Fri, 16 Jan 2026 08:56:13 -0500 [thread overview]
Message-ID: <aWpDfUNbt_V-ipQo@x1.local> (raw)
In-Reply-To: <aWoJAz_GLXzqs_oH@redhat.com>
On Fri, Jan 16, 2026 at 09:46:43AM +0000, Daniel P. Berrangé wrote:
> On Thu, Jan 15, 2026 at 10:59:47PM +0000, Dr. David Alan Gilbert wrote:
> > * Peter Xu (peterx@redhat.com) wrote:
> > > On Thu, Jan 15, 2026 at 10:49:29PM +0100, Lukas Straub wrote:
> > > > Nack.
> > > >
> > > > This code has users, as explained in my other email:
> > > > https://lore.kernel.org/qemu-devel/20260115224516.7f0309ba@penguin/T/#mc99839451d6841366619c4ec0d5af5264e2f6464
> > >
> > > Please then rework that series and consider include the following (I
> > > believe I pointed out a long time ago somewhere..):
> > >
> >
> > > - Some form of justification of why multifd needs to be enabled for COLO.
> > > For example, in your cluster deployment, using multifd can improve XXX
> > > by YYY. Please describe the use case and improvements.
> >
> > That one is pretty easy; since COLO is regularly taking snapshots, the faster
> > the snapshoting the less overhead there is.
>
> Also if we ever want to be able to deprecate the non-multifd migration,
> then we need to ensure multifd migration has the super-set of functionality.
IIUC there's still long way to go for that, and I'm not yet sure if it will
happen..
To achieve it, we'll need to first remove/deprecate multifd capability,
because as long as it's there people can still set it to OFF..
But before that, we'll need to figure out how to do with features
non-trivial to be supported, at least RDMA (it turns out we decided to keep
RDMA, prior to this COLO discussion), and "fd:" URIs.
I still don't know if we can justify nobody will be using some handy
streaming tooling with QEMU migration, in that case it'll never work with
multifd because multifd (even if channels=1) requires two sessions; there's
always the main channel.
So I'd put that aside when considering what we'd do with COLO. In that
case IIUC COLO is the easy part if we really want to always use multifd.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2026-01-16 14:00 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 19:56 [PATCH 0/3] migration: deprecations and removals for 11.0 Peter Xu
2026-01-14 19:56 ` [PATCH 1/3] migration/colo: Deprecate COLO migration framework Peter Xu
2026-01-14 20:11 ` Peter Xu
2026-01-15 21:49 ` Lukas Straub
2026-01-15 22:39 ` Peter Xu
2026-01-15 22:59 ` Dr. David Alan Gilbert
2026-01-15 23:38 ` Peter Xu
2026-01-16 0:37 ` Dr. David Alan Gilbert
2026-01-16 8:16 ` Zhang Chen
2026-01-16 7:47 ` Zhang Chen
2026-01-17 19:49 ` Lukas Straub
2026-01-17 20:15 ` Lukas Straub
2026-01-19 22:33 ` Peter Xu
2026-01-20 11:48 ` Lukas Straub
2026-01-20 15:58 ` Peter Xu
2026-01-20 19:04 ` Dr. David Alan Gilbert
2026-01-20 19:50 ` Peter Xu
2026-01-21 1:25 ` Dr. David Alan Gilbert
2026-01-21 17:03 ` Peter Xu
2026-01-21 17:31 ` Dr. David Alan Gilbert
2026-01-21 20:22 ` Peter Xu
2026-01-21 21:31 ` Dr. David Alan Gilbert
2026-01-21 22:22 ` Peter Xu
2026-01-16 7:05 ` Zhang Chen
2026-01-16 9:46 ` Daniel P. Berrangé
2026-01-16 13:56 ` Peter Xu [this message]
2026-01-16 6:26 ` Markus Armbruster
2026-01-16 8:22 ` Zhang Chen
2026-01-16 9:41 ` Markus Armbruster
2026-01-16 14:08 ` Peter Xu
2026-01-16 15:33 ` Markus Armbruster
2026-01-14 21:13 ` Dr. David Alan Gilbert
2026-01-15 5:56 ` Markus Armbruster
2026-01-15 18:53 ` Peter Xu
2026-01-14 19:56 ` [PATCH 2/3] migration: Remove zero-blocks capability Peter Xu
2026-01-15 6:00 ` Markus Armbruster
2026-01-15 18:53 ` Peter Xu
2026-01-14 19:56 ` [PATCH 3/3] migration: Remove fd: support on files Peter Xu
2026-01-14 22:10 ` Peter Xu
2026-01-15 12:15 ` Prasad Pandit
2026-01-15 17:39 ` Peter Xu
2026-01-15 6:11 ` [PATCH 0/3] migration: deprecations and removals for 11.0 Markus Armbruster
2026-01-15 18:58 ` Peter Xu
2026-01-15 14:37 ` Fabiano Rosas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWpDfUNbt_V-ipQo@x1.local \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dave@treblig.org \
--cc=farosas@suse.de \
--cc=jasowang@redhat.com \
--cc=jmarcin@redhat.com \
--cc=ldoktor@redhat.com \
--cc=lizhijian@fujitsu.com \
--cc=lukasstraub2@web.de \
--cc=qemu-devel@nongnu.org \
--cc=quintela@trasno.org \
--cc=zhangckid@gmail.com \
--cc=zhanghailiang@xfusion.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.