qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Liu Yuan <namei.unix@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	sheepdog@lists.wpkg.org, qemu-devel@nongnu.org,
	MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Subject: Re: [Qemu-devel] [PATCH 2/2] sheepdog: support 'qemu-img snapshot -a'
Date: Thu, 06 Jun 2013 21:09:57 +0800	[thread overview]
Message-ID: <51B08A25.30604@gmail.com> (raw)
In-Reply-To: <20130606124629.GE2586@dhcp-200-207.str.redhat.com>

On 06/06/2013 08:46 PM, Kevin Wolf wrote:
> Am 06.06.2013 um 13:57 hat Liu Yuan geschrieben:
>> Just call sd_create_branch() to rollback the image is good enough
>>
>> Cc: qemu-devel@nongnu.org
>> Cc: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
>> Cc: Kevin Wolf <kwolf@redhat.com>
>> Cc: Stefan Hajnoczi <stefanha@redhat.com>
>> Signed-off-by: Liu Yuan <namei.unix@gmail.com>
>> ---
>>  block/sheepdog.c |    8 +++++---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/block/sheepdog.c b/block/sheepdog.c
>> index 94218ac..cb5ca4a 100644
>> --- a/block/sheepdog.c
>> +++ b/block/sheepdog.c
>> @@ -2072,9 +2072,11 @@ static int sd_snapshot_goto(BlockDriverState *bs, const char *snapshot_id)
>>      }
>>  
>>      if (!s->inode.vm_state_size) {
>> -        error_report("Invalid snapshot");
>> -        ret = -ENOENT;
>> -        goto out;
>> +        /* qemu-img asks us to rollback, we need to do it right now */
>> +        ret = sd_create_branch(s);
>> +        if (ret) {
>> +            goto out;
>> +        }
>>      }
> 
> I'm not sure how snapshots work internally for Sheepdog, but it seems
> odd to me that you need to do this only for disk-only snapshots, but not
> when the snapshot has VM state. (Also, note that 'qemu-img snapshot -a'
> works on images with a VM state, so the comment doesn't seem to be
> completely accurate)
> 
> Would you mind explaining to me how this works in detail?
> 

Hmm, the original code isn't written by me and this snapshot mechanism
exists since day 0. I just hacks it to work now. So I'll try to explain
on my understanding.

When we do a snapshot such as 'savedvm' or 'qemu-img snapshot', the
active vdi is snapshotted and marked as snapshot and a new vdi is
created as copy-on-write on the previous active vdi, then this new vdi
becomes active vdi. For e.g,

As1 --> As2 --> A

We take snapshot of vdi A twice, tagged s1 and s2 respectively. I guess
this is quit similar to qcow2 snapshots, only inode object with a bitmap
is created.

So when we 'loadvm' or 'qemu-img snapshot -a' to A, current logic just
handle 'loadvm', that .bdrv_snapshot_goto only reloads inode object,
that is, for e.g, we 'savevm s1', and mark it as snapshot, the chain
would like

As1 --> As2 --> A
 |
 v
 just reload As1's inode object

Only when the write comes from VM, we do the following stuff
 - delete active vdi A
 - created a new inode based on the previously reloaded As1's inode

The chain will look like:

As1 --> As2
 |
 V
 A

This is how sheepdog handles savevm/loadvm.

So for 'qemu-img snapshot -a', we should create the branch in the
.bdrv_snapshot_goto.

As you pointed out, we need to consider vm state even for 'snapshot -a',
so I need to rework the patch 2/2.

Thanks,
Yuan

  reply	other threads:[~2013-06-06 13:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-06 11:57 [Qemu-devel] [PATCH 0/2] fix 'qemu-img snapshot -a' operation for sheepdog Liu Yuan
2013-06-06 11:57 ` [Qemu-devel] [PATCH 1/2] sheepdog: fix snapshot tag initialization Liu Yuan
2013-06-06 12:46   ` Kevin Wolf
2013-06-06 11:57 ` [Qemu-devel] [PATCH 2/2] sheepdog: support 'qemu-img snapshot -a' Liu Yuan
2013-06-06 12:46   ` Kevin Wolf
2013-06-06 13:09     ` Liu Yuan [this message]
2013-06-07  7:31       ` Kevin Wolf
2013-06-07 13:48         ` Liu Yuan
2013-06-07 15:22           ` Kevin Wolf
2013-06-07 16:14             ` Liu Yuan
2013-06-07 16:48               ` Kevin Wolf
2013-06-07 17:23                 ` Liu Yuan
2013-06-06 13:41     ` Liu Yuan

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=51B08A25.30604@gmail.com \
    --to=namei.unix@gmail.com \
    --cc=kwolf@redhat.com \
    --cc=morita.kazutaka@lab.ntt.co.jp \
    --cc=qemu-devel@nongnu.org \
    --cc=sheepdog@lists.wpkg.org \
    --cc=stefanha@redhat.com \
    /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).