On Wed, Jan 21, 2026 at 09:31:29PM +0000, Dr. David Alan Gilbert wrote: > * Peter Xu ([email protected]) 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
