Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru> wrote: > On 23.04.23 04:54, Zhang, Chen wrote: >> >>> -----Original Message----- >>> From: Vladimir Sementsov-Ogievskiy<vsement...@yandex-team.ru> >>> Sent: Friday, April 21, 2023 4:36 PM >>> To: Zhang, Chen<chen.zh...@intel.com>;qemu-de...@nongnu.org >>> Cc:qemu-block@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;lizhij...@fujitsu.com >>> Subject: Re: [PATCH v2 3/4] build: move COLO under CONFIG_REPLICATION >>> >>> 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-de...@nongnu.org >>>>> Cc:qemu-block@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. >> In the patch 7e934f5b27eee1b0d7 said it's for current independent disk mode, >> And what we talked about before is the shared disk mode. >> Rethink about the COLO shared disk mode, this feature still needs some >> enabling works. >> It looks OK for now and separate the build options when enabling COLO shared >> disk mode. > > I've started working on this, and now I see, that check in the > migrate_caps_check() is not the only place. > > migration/colo.c has also several abort() points. For example, > colo_process_checkpoint will simply abort if CONFIG_REPLICATION not > defined. > > So for sure, current code is not prepared to use COLO with REPLICATION > disabled. > > If this possibility is needed it requires more work. Personally, I > don't think that possibility to enable COLO with disabled REPLICATION > is really needed and I know nobody who need it, so that seems to be > extra work.
Whoever does the work to make COLO without REPLICATION work, it can also do the aditional work of splitting it. Changing a configure file is going to be the smaller of its problems. Later, Juan.
