On 21.04.23 06:02, Zhang, Chen wrote:
-----Original Message-----
From: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru>
Sent: Thursday, April 20, 2023 6:53 AM
To: qemu-devel@nongnu.org
Cc: qemu-bl...@nongnu.org; michael.r...@amd.com; arm...@redhat.com;
ebl...@redhat.com; jasow...@redhat.com; quint...@redhat.com; Zhang,
Hailiang <zhanghaili...@xfusion.com>; phi...@linaro.org;
th...@redhat.com; berra...@redhat.com; marcandre.lur...@redhat.com;
pbonz...@redhat.com; d...@treblig.org; hre...@redhat.com;
kw...@redhat.com; Zhang, Chen <chen.zh...@intel.com>;
lizhij...@fujitsu.com; Vladimir Sementsov-Ogievskiy <vsementsov@yandex-
team.ru>
Subject: [PATCH v2 3/4] build: move COLO under CONFIG_REPLICATION
We don't allow to use x-colo capability when replication is not configured. So,
no reason to build COLO when replication is disabled, it's unusable in this
case.
Yes, you are right for current status. Because COLO best practices is
replication + colo live migration + colo proxy.
But doesn't mean it has to be done in all scenarios as I explanation in V1.
The better way is allow to use x-colo capability firstly, and separate this
patch
with two config options: --disable-replication and --disable-x-colo.
But what for? We for sure don't have such scenarios now (COLO without
replication), as it's not allowed by far 7e934f5b27eee1b0d7 (by you and David).
If you think we need such scenario, I think it should be a separate series
which reverts 7e934f5b27eee1b0d7 and adds corresponding test and probably
documentation.
--
Best regards,
Vladimir
