qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 02/10] block: set snapshot option for block d


From: Pavel Dovgalyuk
Subject: Re: [Qemu-devel] [PATCH v2 02/10] block: set snapshot option for block devices in blkreplay module
Date: Fri, 16 Sep 2016 10:55:42 +0300

> From: Paolo Bonzini [mailto:address@hidden
> 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? 

Right.

> 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 
overlay.

I don't think that it is convenient forcing user to create overlay manually.
Common debugging scenario includes multiple recording passes until the bug 
manifests
itself. Every new execution recorded should be accompanied by creating an 
overlay
to assure that the execution is started from the same disk state.

Specifying initial snapshot name makes sense if we want to suppress -loadvm 
option.
Then replay may be started from any state without using -loadvm.

Pavel Dovgalyuk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]