On 12/19/2016 09:03 AM, Christopher Pereira wrote:
> Hi Fam, Stefan,
> 
> Thanks for answering.
> 
> We use "qemu-img convert" to convert a image in the middle of the chain,
> not the active one.
> Those images (and the previous ones in the chain) are read-only and
> there should be no risk in converting them:
> 
> E.g.: for the following chain:
> 
>    base --> snap1 ---> snap2 ---> snap3 (active)

We typically write that as:

base <- snap1 <- snap2 <- snap3

where the <- operator can be pronounced "backs", and where the direction
of the arrow shows that it is snap1 that depends on base (and not base
that depends on snap1).

> 
> we do "qemu-img convert" on snap2 (readonly), generating a snap2' with
> the same content as snap2.

That part is fine, but why not use QMP to let qemu generate a single
file with the same contents, instead of delegating to qemu-img?

> 
> Then we do the rebase while the VM is suspended to make sure the image
> files are reopened.
> 
> Please confirm if I'm missing something here.

That part is where you are liable to break things.  Qemu does NOT have a
graceful way to reopen the backing chain, so rebasing snap3 to point to
snap2' behind qemu's back is asking for problems.  Since qemu may be
caching things it has already learned about snap2, you have invalidated
that cached data by making snap3 point to snap2', but have no way to
force qemu to reread the backing chain to start reading from snap2'.

But if you would use qemu block-commit to merge "base <- snap1 <- snap2"
into "base'", then the block-commit command will gracefully take care of
rewriting the backing image of snap3 to now point to base.  You achieve
the same result, but without the need for an external qemu-img call,
without the need to pause the guest, and the only thing you have to be
careful of is dealing with the difference in file names.

Or, if you don't want to merge into "base'", you can use block-stream to
merge the other direction, so that "base <- snap1 <- snap2" is converted
into "snap2'" - but that depends on patches that were only barely added
in qemu 2.8 (intermediate block-commit has existed a lot longer than
intermediate block-stream).  But the point remains that you are still
using qemu to do the work, and therefore with no external qemu-img
process interfering with the chain, you don't need any guest downtime or
any risk of breaking qemu operation by invalidating data it may have cached.

> 
> We are not using block-commit since we want to have more control (keep
> the base snapshot unmodified, use compression, etc).

If block-commit and block-stream don't have enough power to do what you
want, then we should patch them to expose that power, rather than
worrying about how to use qemu-img to modify the backing chain behind
qemu's back.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org