Re: [Qemu-devel] block-commit & dropping privs

[Jeff Cody]

On Thu, Apr 02, 2015 at 01:24:02PM +0200, Kevin Wolf wrote:
> Am 02.04.2015 um 12:58 hat Michael Tokarev geschrieben:
> > 01.04.2015 15:34, Kevin Wolf wrote:
> > []
> > > Overriding the backing file should work like this:
> > > 
> > >     -drive file=...,backing.file.filename=/dev/fdset/2
> > 
> > Oh-ok, this works.  Sort of.
> > 
> > Because after performing commit (is there a difference between
> > commit hmp command and block-commit qmp command?  I used the
> > former so far),
> 
> Yes, two completely different implementations. HMP 'commit' is a
> non-live version that effectively pauses the VM while it runs.
> 
> Apparently the live version (which is QMP 'block-commit') isn't
> available in HMP. Jeff, do you remember why?
> 
> qemu-img commit reuses the QMP code today.
>

IIRC, it was because the live commit was, by definition, live.  And
the original HMP commit operated on the active layer (and the active
layer only), and the live commit originally did not.  So the HMP
commit provided functionality that was not in the QMP block-commit.

> > the new backing file name is recorded to the
> > qcow2 file header, and now, qemu-img can't operate on this
> > file anymore, telling me it can't access backing file due
> > to bad file descriptor.
> 
> Right. That's why block-commit has an optional 'backing-file' argument
> that contains the new backing file string to be written to the file.
> 
> > So in order to finally commit the file I used qemu-system
> > again, running it like that specifying backing file, but
> > with -S option, and issued `commit' command again.
> > 
> > I noticed that I can't specify backing file for
> > qemu-img commit.
> > 
> > But overall, I think qemu-system should not modify backing
> > file name in this case.
> 
> So you would leave the backing file with the data that you just
> committed down one level in your backing file chain? Wouldn't that
> defeat the whole purpose of committing?
> 
> > When performing commit, does qemu mark the areas in the
> > overlay file as free after writing contents to the backing
> > file, or will these areas be written again by a subsequent
> > commit?  Somehow it smells like each next commit writes
> > more and more data and completes in more and more time.
> 
> With qcow2 and qcow, the committed data is discarded with HMP 'commit'.
> Other image formats keep the copy.
> 
> Live commit always keeps the data in the parent image, but it drops that
> image from the backing file chain, so effectively it is dropped as well
> (but you need to remove the file manually to reclaim the space).
> 
> Jeff, this sounds like we need to make some changes to unify this. That
> might mean introducing an option that decides whether an image should be
> dropped from the chain or emptied.

Yes, I think this would be a good idea.  I can think of scenarios
where we would want to keep the original overlay around (i.e., we
still want a snapshot overlay, but just want to consolidate data).
But I can't think of any reason we would want to keep a stale
populated overlay file around.

> Once live commit can provide the same
> as HMP commit, we should change HMP commit to reuse the live commit
> code.
> 

Hmm. My concern here is there may be times we want the behavior that
HMP commit provides - faster offline active layer commit, rather than
a mirror-like operation.  I guess if we do want that behavior,
however, we could always introduce it as an option to block-commit.
So yes, let's provide an option to remove or empty the committed
overlays (applies to all overlays, if there are multiple overlays
being committed in the chain), and then have HMP commit reuse the live
commit code.