qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Huan Zhang <huan.zhang.jn@gmail.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
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	[thread overview]
Message-ID: <568D3517.7030401@redhat.com> (raw)
In-Reply-To: <CAFU9Conh77-Xgib5MAFnmFE7OVt19A=KgB0=Da=Rk47B-9Bcrw@mail.gmail.com>

[-- 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 --]

      parent reply	other threads:[~2016-01-06 15:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30 11:31 [Qemu-devel] could i using qemu-img covert && rebase -u to do qcow2 rollback? Huan Zhang
2015-12-31  1:12 ` Huan Zhang
2016-01-04 17:45 ` Max Reitz
2016-01-04 17:54   ` Eric Blake
     [not found]   ` <CAFU9Conh77-Xgib5MAFnmFE7OVt19A=KgB0=Da=Rk47B-9Bcrw@mail.gmail.com>
2016-01-06 15:39     ` Max Reitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=568D3517.7030401@redhat.com \
    --to=mreitz@redhat.com \
    --cc=huan.zhang.jn@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).