[PATCH 15/32] qemublocktest: Replace 'snapshots' bitmap detection test case data

Peter Krempa pkrempa at redhat.com
Thu Jun 18 15:13:13 UTC 2020


On Thu, Jun 18, 2020 at 09:58:35 -0500, Eric Blake wrote:
> On 6/15/20 12:10 PM, Peter Krempa wrote:
> > Use test data which conforms to the new semantics which changed in the
> > previous patch.
> 
> Well, a recent patch (the previous patch only touched tests, rather than
> changing semantics)
> 
> > 
> > The test data was created by the same set of commands as originally in
> > commit 0b27b655b1bac480186ce80457113cd5dc34e6a1
> > 
> > Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> > ---
> >   tests/qemublocktestdata/bitmap/snapshots.json | 1382 +++++++----------
> >   tests/qemublocktestdata/bitmap/snapshots.out  |   13 +-
> >   2 files changed, 588 insertions(+), 807 deletions(-)
> 
> > +++ b/tests/qemublocktestdata/bitmap/snapshots.out
> > @@ -1,12 +1,17 @@
> >   libvirt-1-format:
> > -        d: record:0 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        d: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        a: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        b: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        c: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> >     current: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> 
> So, where the old paradigm stitched bitmaps across snapshots (no need to add
> a bitmap to a new snapshot layer if it was already inactive in the old
> layer), the new paradigm says that every reachable checkpoint must have an
> active bitmap in the current layer, in addition to whatever bitmaps it had
> in earlier layers.
> 
> Presumably, upcoming patches will tweak libvirt to actually create these
> bitmaps as part of creating an external snapshot, and I also see how you
> could utilize qemu adding block-dirty-bitmap-populate as a convenient way
> for re-creating such bitmaps after the fact (any bitmap that exists in the
> backing chain should basically mirror the allocation of the current layer in
> the chain).

They are actually already being created by 'qemuDomainSnapshotDiskBitmapsPropagate',
and that code is still valid. But I've noticed that the comment needs to
be fixed probably.




More information about the libvir-list mailing list