On Mon, 05/14 13:23, Vladimir Sementsov-Ogievskiy wrote: > > So, you agree, that dropping all bitmaps after inactivation is good > > idea.. The second question, is it possible to not drop them? Is there a > > way, to check that disk was not changed after pair of > > inactivate-invalidate? I have an idea: > > we can create small-bitmap, which will not migrate through migration > > channel, but remain persistent. It will be very small (big granularity, > > to not increase downtime of migration), so after invalidate we can check > > this bitmap. If it is empty, we are happy, we can "activate" all our > > bitmaps and make them persistent again. If not, we have two ways: > > > > 1. drop all bitmaps > > 2. merge small-bitmap to all our bitmaps > > However, we must not start source, if disk was changed, as memory and > devices states will not correspond to disk. So, such a small bitmap may be > used to check, can we start source or not.
Or it can be a generation number/uuid that is updated when the image is changed (upon the first write after each open), similar to VMDK's CID and VHDX GUIDs. We can compare the on disk value with the known value at source QEMU, if they match it means the image data is not touched. Fam
