> From: Kevin Wolf [mailto:kw...@redhat.com] > Am 05.12.2016 um 12:49 hat Pavel Dovgalyuk geschrieben: > > > From: Kevin Wolf [mailto:kw...@redhat.com] > > > Am 05.12.2016 um 08:43 hat Pavel Dovgalyuk geschrieben: > > > Record/replay without this option uses '-snapshot' to preserve > > the state of the disk images. > > > > > Anyway, it seems that doing things manually is the safe way as long as > > > we don't know the final solution, so I think I agree. > > > > > > For a slightly more convenient way, one of the problems to solve seems > > > to be that snapshot=on always affects the top level node and you can't > > > create a temporary snapshot in the middle of the chain. Perhaps we > > > should introduce a 'temporary-overlay' driver or something like that, so > > > that you could specify things like this: > > > > > > -drive if=none,driver=file,filename=test.img,id=orig > > > -drive if=none,driver=temporary-overlay,file=orig,id=snap > > > -drive if=none,driver=blkreplay,image=snap > > > > This seems reasonable for manual way. > > Maybe another, easier to implement option could be something like this: > > -drive > if=none,driver=file,filename=test.img,snapshot=on,overlay.node-name=snap > -drive if=none,driver=blkreplay,image=snap > > It would require that we implement support for overlay.* options like we > already support backing.* options. Allowing to specify options for the > overlay node is probably nice to have anyway. > > However, there could be a few tricky parts there. For example, what > happens if someone uses overlay.backing=something-else? Perhaps > completely disallowing backing and backing.* for overlays would already > solve this. > > > > Which makes me wonder... Is blkreplay usable without the temporary > > > snapshot or is this pretty much a requirement? > > > > It's not a requirement. But to make replay deterministic we have to > > start with the same image every time. As I know, this may be achieved by: > > 1. Restoring original disk image manually > > 2. Using vm snapshot to start execution from > > 3. Using -snapshot option > > 4. Not using disks at all > > > > > Because if it has to be > > > there, the next step could be that blkreplay creates temporary-overlay > > > internally in its .bdrv_open(). > > > > Here is your answer about such an approach :) > > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04687.html > > Right, and unfortunately these are still good points. > > Especially the part where you allowed to give the overlay filename > really needs to work the way it does now with the 'image' option. We > might not need to be that strict with temporary overlays, restricting to > qcow2 with default options could be acceptable there - but whatever I > think of to support both cases results in something that isn't really > easier than the manual way that we figured out above.
Can we stop on the following? 1. Don't create any overlays automatically when user wants to save/restore VM state 2. In the opposite case create snapshots, but do not use -snapshot option. Snapshots will be created by the blkreplay as in the link specified. Pavel Dovgalyuk
