All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.