Re: [Qemu-devel] QCOW rebases on running VMs

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

On 27.01.2016 19:04, Alex Bligh wrote:
> This question concerns the safety of rebases on backing disks whilst a VM is running from a writing disk.
> 
> Assume that we have the following structure:
> 
>     QEMU ------->   Writing disk
>                     ....
>                     backing disk N
>                     ....
>                     backing disk 1
>                     ....
>                     backing disk 0
> 
> If QEMU is not running, I can happily use 'qemu-img rebase' to merge backing disks 1 ... N (i.e. so backing disk N is now based on backing disk 0).
> 
> Is it safe to do this whilst the server is running using the writing disk which is based on backing disk N?

Maybe. You would rebase 1 through N into a new file and change the
backing file of the writing disk to the new file; because qemu is not
writing to the backing disks, that should probably work, but it's not
nice and may break horribly without prior notice.

> It is attractive to think it might be, as even if QEMU has a stale view of the contents of backing disk N, backing disks N-1 to 1 (inclusive) will still be present, QEMU will still keep an fd open for them, and it will (thus) still be able to read the correct sectors from them.
> 
> If not, do I need to use QMP magic instead?

This is always the best option, and I would strongly recommend doing so.
block-stream or block-commit should be your friend. block-stream streams
data from backing files into backed files, block-commit pushes data from
backed files into backing files; so block-stream transmits data from
bottom to top, and block-commit transmits it from top to bottom.

With block-commit, you can collapse the backing chain to e.g. (from top
to bottom):

Writing disk -> backing disk 1..N -> backing disk 0

like this (I think):

{ 'execute': 'block-commit',
  'arguments': { 'device': '$drive',
                 'base': 'backing disk 1',
                 'top': 'backing disk N' } }

The "backing disk 1..N" is the file which contained "backing disk 1" and
now contains all the data from disks 1 through N.


With block-stream, you can collapse it into

Writing disk -> backing disk 0

like this:

{ 'execute': 'block-stream',
  'arguments': { 'device': '$drive',
                 'base': 'backing disk 0' } }

Here, the writing disk would contain all the data from backing disks 1
through N. You could omit the "base" option, in which case the whole
backing chain would be collapsed into the writing disk.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]