qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] could i using qemu-img covert && rebase -u to do qcow2


From: Max Reitz
Subject: Re: [Qemu-devel] could i using qemu-img covert && rebase -u to do qcow2 rollback?
Date: Wed, 6 Jan 2016 16:39:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 05.01.2016 04:52, Huan Zhang wrote:
> Hi Max,
> "rollback" means revert user data to snap1 state, and for some reason,
> we want to
> keep snap2 and  'rollbacked' qocw2 file in a single backing file chain.
> After rollback, looks like:
> snap0.qcow2 -> snap1.qcow2 ->snap2.qcow2 -> rollbacked-snap1.qcow2
>  
> In my immature opinion,
> 'qemu-img convert -O qcow2 snap1.qcow2 rollback.qcow2' get snap1 sate data,
> 'qemu-img rebase -u -b snap2.qcow2 rollback.qcow2' just changes
> rollback.qcow2 backing file to snap2.qcow2,
> will NOT change the data from user perspective(data reading from backing
> file (snap2.qcow2 e.g.) which not in rollback.qcow2 is meaningless to user].
> Is that right?

OK. The problem with this is that qemu-img convert will not write
unallocated clusters. For instance, assume we have the following
configuration:

# An empty snap0.qcow2
$ qemu-img create -f qcow2 snap0.qcow2 64M

# snap1.qcow2 contains some 64k data block at offset 0
$ qemu-img create -f qcow2 -b snap0.qcow2 -F qcow2 snap1.qcow2
$ qemu-io -c 'write -P 1 0 64k' snap1.qcow2

# snap2.qcow2 contains some other 64k data block at offset 64k
$ qemu-img create -f qcow2 -b snap1.qcow2 -F qcow2 snap2.qcow2
$ qemu-io -c 'write -P 2 64k 64k' snap2.qcow2

# Now you want to rollback to snap1
$ qemu-img convert -O qcow2 snap1.qcow2 rollback.qcow2
$ qemu-img rebase -u -b snap2.qcow2 rollback.qcow2

# Now let's compare snap1.qcow2 and rollback.qcow2
$ qemu-img compare snap1.qcow2 rollback.qcow2
Content mismatch at offset 65536!

So what went wrong? qemu-img convert does not write unallocated sectors
to the output; therefore, the block starting from offset 64k is
unallocated in rollback.qcow2 (just as it is in snap1.qcow2), however,
in rollback.qcow2, this will not return 0, but whatever is in
snap2.qcow2 (which snap1.qcow2 does not have as a backing file).
Therefore, when read from snap1.qcow2, that range is 0; but from
rollback.qcow2, it returns 2s (what we wrote to snap2.qcow2).

How to fix it? Drop the -u for rebase. However, qemu-img will not let us
do this because without -u it wants the image to have a backing file
already.

So let's make rollback.qcow2's backing file snap0.qcow2 (the backing
file snap1.qcow2 has):

$ qemu-img convert -O qcow2 \
    -o backing_file=snap0.qcow2,backing_fmt=qcow2 \
    snap1.qcow2 rollback.qcow2

(So in the general case, the backing_file option should be set to
whatever backing file snap1.qcow2 has.)

Alternatively, since you will actually be doing a rebase after this, you
can also simply do:

$ cp snap1.qcow2 rollback.qcow2

Whatever you choose (the second may actually be the better choice), the
rebase can be done using:

$ qemu-img rebase -b snap2.qcow2 -F qcow2 rollback.qcow2

Now let's check:

$ qemu-img compare snap1.qcow2 rollback.qcow2
Images are identical.

That looks better!


So, conclusion, the following will probably generally do:

$ cp snap1.qcow2 rollback.qcow2
$ qemu-img rebase -b snap2.qcow2 -F qcow2 rollback.qcow2

Where snap1.qcow2 is the state you want to roll back to, and snap2.qcow2
is the last image you want to be in the backing chain under rollback.qcow2.


Hope that helps (and that I'm actually correct),

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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