qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Reitz
Subject: Re: [Qemu-devel] QCOW rebases on running VMs
Date: Wed, 27 Jan 2016 20:01:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]