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

[Kevin Wolf <kwolf@redhat.com>]

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.

> 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. Once live commit can provide the same
as HMP commit, we should change HMP commit to reuse the live commit
code.

Kevin