> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 15/09/2016 11:00, Pavel Dovgalyuk wrote:
> > diff --git a/docs/replay.txt b/docs/replay.txt
> > index 347b2ff..5be8f25 100644
> > --- a/docs/replay.txt
> > +++ b/docs/replay.txt
> > @@ -196,6 +196,14 @@ is recorded to the log. In replay phase the queue is
> > matched with
> > events read from the log. Therefore block devices requests are processed
> > deterministically.
> > +blkdriver also supports overlay option, which allows creating persistent
> > +overlay file for saving and reloading VM snapshots in record/replay modes.
> > +Replay mechanism automatically creates one snapshot named 'replay_init' to
> > +allow rewinding execution while replaying.
> > +Overlay file may be specified as follows:
> > + -drive driver=blkreplay,if=none,image=img-direct,
> > + overlay=overlay.qcow2,id=img-blkreplay
> So in this case the image is actually overlay.qcow2, and it is created
> with img-direct as the backing file?
> Since you have to create
> overlay.qcow2 outside QEMU anyway, overlay.qcow2 might as well be the
> "image". That is, you could choose between:
> -drive driver=blkreplay,if=none,image=overlay.qcow2,id=img-blkreplay \
> -rr snapshot=replay_init,...
> -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay
> The temporary snapshot would be created if there's no "-rr snapshot" option
> on the command line.
> Does this make sense?
There are two different parts:
- creating an overlay
- creating the snapshot
Overlay is needed to preserve the state of the original backing file.
In the current version temporary overlay is always created at start of qemu.
Then all changes are destroyed at exit and disk remain the same.
It allows replaying the execution from the same disk state.
To allow reverse execution we have to create some snapshots, that will allow
rewinding the execution. Snapshots have to be written on some non-temporary
I don't think that it is convenient forcing user to create overlay manually.
Common debugging scenario includes multiple recording passes until the bug
itself. Every new execution recorded should be accompanied by creating an
to assure that the execution is started from the same disk state.
Specifying initial snapshot name makes sense if we want to suppress -loadvm
Then replay may be started from any state without using -loadvm.