Re: [PATCH 1/3] migration/colo: Deprecate COLO migration framework

[Peter Xu <peterx@redhat.com>]

On Wed, Jan 21, 2026 at 09:31:29PM +0000, Dr. David Alan Gilbert wrote:
> * Peter Xu (peterx@redhat.com) wrote:
> > On Wed, Jan 21, 2026 at 05:31:32PM +0000, Dr. David Alan Gilbert wrote:
> > > Right that's true for postcopy; but then the only way to load the stream into
> > > that buffer is to load it all at once because of the vmstate problem above.
> > > (and because in the original postcopy we needed the original fd free
> > > for page requests; you might be able to avoid that with multifd now)
> > 
> > Only until now, I recognized that COLO wants to make sure the checkpoint is
> > either completely applied or none applied.
> > 
> > So the specialty is COLO does loadvm on top of a running VM, meanwhile COLO
> > may decide to not loadvm afterwards if checkpoint wasn't correctly
> > received.
> 
> Oh yes; because if your secondary is running happily, your primary could
> fail while it was sending you a new snapshot - and then the secondary
> has to be able to carry on.
> 
> > And yes, to cache all device states with current section header definition
> > in the stream, we'll likely need a size.  We can still parse the stream as
> > you pointed out previously, but I agree a special SIZE header still makes
> > sense.
> 
> Well, *can't* parse the stream as I said; because of the get()/put() stuff
> without rewriting that.

Ah, yes..

-- 
Peter Xu