Re: [Qemu-devel] [PATCH v5 7/9] block: don't make snapshots for filters

[Kevin Wolf <kwolf@redhat.com>]

Am 28.09.2016 um 14:49 hat Pavel Dovgalyuk geschrieben:
> > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > Am 28.09.2016 um 11:32 hat Pavel Dovgalyuk geschrieben:
> > > > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > > > Am 27.09.2016 um 16:06 hat Pavel Dovgalyuk geschrieben:
> > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > > > > > Am 26.09.2016 um 11:51 hat Pavel Dovgalyuk geschrieben:
> > > > > > > > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > > > > > > > Am 26.09.2016 um 10:08 hat Pavel Dovgalyuk geschrieben:
> > > > > > Originally, we only called bdrv_goto_snapshot() for all _top level_
> > > > > > BDSes, and this is still what you normally get. However, if you
> > > > > > explicitly create a BDS (e.g. with its own -drive option), it is
> > > > > > considered a top level BDS without actually being top level for the
> > > > > > guest, and therefore the snapshotting function is called for it.
> > > > > >
> > > > > > Of course, this is highly inefficient because the goto_snapshot request
> > > > > > is passed by the filter driver and then called another time for the
> > > > > > lower node, effectively loading the snapshot a second time.
> > >
> > > Maybe double-saving/loading does the smallest damage then?
> > > And we should just document how to use blkreplay effectively?
> > >
> > > > > >
> > > > > > On the other hand if you use a single -drive option to create both the
> > > > > > qcow2 BDS and the blkreplay filter, we do need to pass down the
> > > > > > goto_snapshot request because it won't be called for the qcow2 layer
> > > > > > otherwise.
> > > > >
> > > > > How this can be specified in command line?
> > > > > I believed that separate -drive option is required.
> > > >
> > > > Something like this:
> > > >
> > > >     -drive driver=blkreplay,image.driver=file,image.filename=test.img
> > > >
> > >
> > > I tried the following command line, but VM does not detect the hard drive
> > > and cannot boot.
> > >
> > > -drive driver=blkreplay,if=none,image.driver=file,image.filename=testdisk.qcow,id=img-
> > blkreplay
> > > -device ide-hd,drive=img-blkreplay
> > 
> > My command line was assuming a raw image. It looks like you're using a
> > qcow (hopefully qcow2?) image. If so, then you need to include the qcow2
> > driver:
> > 
> > -drive driver=blkreplay,if=none,image.driver=qcow2,\
> > image.file.driver=file,image.file.filename=testdisk.qcow,id=img-blkreplay
> 
> This doesn't work for some reason. Replay just hangs at some moment.
> 
> Maybe there exists some internal difference between command line with one or two -drive options?

There are some subtle differences that affect the management of the
block driver nodes, but they shouldn't make a difference for the I/O
path. But I don't know the replay code well, so maybe it makes a
difference there (which would be a bug).

If you have two separate -drive options, a BlockBackend is created for
each of them. The lower layer one wouldn't be used normally, but if you
iterate over all BlockBackends somewhere, you would see it. Both BBs are
owned by the monitor, and if you remove the top layer, the monitor
reference will keep the lower layer alive.

In contrast, with a single -drive option, only the top layer (blkreplay)
has a BlockBackend attached, but the qcow2 layer doesn't. If the
blkreplay BlockBackend is deleted, the qcow2 layer automatically goes
away as well because the monitor doesn't hold a reference to it.

I think these are the most important (and possibly the only)
differences.

Kevin