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

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

[Huan Zhang]

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

Hi,
We are finding a way to do rollback for qcow2 in production environment,
But we can't ensure the below way will work well, and user data are safe.

for example,
snap0.qcow2 -> snap1.qcow2 ->snap2.qcow2 -> active.qcow2

rollback to snap1 using convert && rebase -u:
1. qemu-img convert -O qcow2 snap1.qcow2 rollback.qcow2
2. qemu-img -u -b snap2.qcow2 rollback.qcow2

Test pass with data.  But in theory, could someone give me a positive
answer?

Appreciate to get your reply!


Best Regards.
Huan Zhang.

[-- Attachment #2: Type: text/html, Size: 846 bytes --]

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

[Huan Zhang]

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

Hi,
Could you give me some help?
Thanks very much.

Best Regards.

2015-12-30 19:31 GMT+08:00 Huan Zhang <huan.zhang.jn@gmail.com>:

> Hi,
> We are finding a way to do rollback for qcow2 in production environment,
> But we can't ensure the below way will work well, and user data are safe.
>
> for example,
> snap0.qcow2 -> snap1.qcow2 ->snap2.qcow2 -> active.qcow2
>
> rollback to snap1 using convert && rebase -u:
> 1. qemu-img convert -O qcow2 snap1.qcow2 rollback.qcow2
> 2. qemu-img -u -b snap2.qcow2 rollback.qcow2
>
> Test pass with data.  But in theory, could someone give me a positive
> answer?
>
> Appreciate to get your reply!
>
>
> Best Regards.
> Huan Zhang.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1440 bytes --]

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

[Max Reitz]

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

On 30.12.2015 12:31, Huan Zhang wrote:
> Hi,
> We are finding a way to do rollback for qcow2 in production environment,
> But we can't ensure the below way will work well, and user data are safe.
> 
> for example,
> snap0.qcow2 -> snap1.qcow2 ->snap2.qcow2 -> active.qcow2
> 
> rollback to snap1 using convert && rebase -u:
> 1. qemu-img convert -O qcow2 snap1.qcow2 rollback.qcow2
> 2. qemu-img rebase -u -b snap2.qcow2 rollback.qcow2

What do you mean by "rollback"? Just getting back to the state presented
in snap1, discarding all the changes done in snap2 and active?

Then why don't you just throw snap2.qcow2 and active.qcow2 away and
continue to work on snap1.qcow2? If you want to keep snap1 in its
current state, just create a new image on top of it:

$ qemu-img create -f qcow2 -b snap1.qcow2 active.qcow2

Anyway, the qemu-img rebase line looks fishy to me. What you are doing
is using snap2.qcow2 as a backing file of snap1.qcow2, basically, and
this is just the wrong way around than it was before.

Max


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

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

[Eric Blake]

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

On 01/04/2016 10:45 AM, Max Reitz wrote:
> On 30.12.2015 12:31, Huan Zhang wrote:
>> Hi,
>> We are finding a way to do rollback for qcow2 in production environment,
>> But we can't ensure the below way will work well, and user data are safe.
>>
>> for example,
>> snap0.qcow2 -> snap1.qcow2 ->snap2.qcow2 -> active.qcow2
>>
>> rollback to snap1 using convert && rebase -u:
>> 1. qemu-img convert -O qcow2 snap1.qcow2 rollback.qcow2
>> 2. qemu-img rebase -u -b snap2.qcow2 rollback.qcow2
> 
> What do you mean by "rollback"? Just getting back to the state presented
> in snap1, discarding all the changes done in snap2 and active?
> 
> Then why don't you just throw snap2.qcow2 and active.qcow2 away and
> continue to work on snap1.qcow2? If you want to keep snap1 in its
> current state, just create a new image on top of it:
> 
> $ qemu-img create -f qcow2 -b snap1.qcow2 active.qcow2

Don't forget to also set the backing format (either '-o
backing_fmt=qcow2' or the undocumented '-F qcow2').  Without an explicit
format, libvirt will default to refusing to honor your backing files
rather than risk an unsafe format probe.

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


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

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

[Max Reitz]

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

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]