All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org,
	dietmar@proxmox.com
Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd
Date: Fri, 19 Jul 2013 17:03:15 +0800	[thread overview]
Message-ID: <51E900D3.30705@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130718054350.GE26971@stefanha-thinkpad.redhat.com>

于 2013-7-18 13:43, Stefan Hajnoczi 写道:
> On Wed, Jul 17, 2013 at 10:03:51PM +0800, Wenchao Xia wrote:
>> This series allow user to read internal snapshot's contents without qemu-img
>> convert. Another purpose is that, when qemu is online and have taken an
>> internal snapshot, let user invoke qemu-nbd to do any thing on it except write.
>
> I agree with Eric and Kevin that we cannot access image files while QEMU
> has them open.
>
> A bit more detail about using the run-time NBD server to do this safely:
>
> Internal snapshots are not first-class block layer objects today.  They
> are not BlockDriverStates, instead you must access their data through
> bdrv_snapshot_goto() or bdrv_snapshot_load_tmp().
>
   Also cc to Fam Zheng an Kevin:
   I think BlockDriverStates modification, is based on a more basic
question: does qcow2's data structure on disk, allow multiple snapshot
reader, while one active writer, without lock? I think the modification
showed above, already said "yes" to this question. If yes, just
create a new BlockDriverStates, we should say yes in spec.
   I wonder how vmdk allow direct snapshot access by VixDiskLib 1.1,
without network expense on host, it should be the format said support
of it.




> The problem with these functions is that they use the BlockDriverState.
> So the guest cannot write to the main image while an internal snapshot
> is loaded.
>
> This can be solved by introducing a function that creates a read-only
> internal snapshot BlockDriverState which is partially independent of the
> main image BlockDriverState that the guest is accessing.
>
> The challenge is implementing this cleanly:
>
> 1. The lifecycle of the main image BlockDriverState and the read-only
>     internal snapshot BlockDriverState is related.  What happens when the
>     main image BDS is deleted but the snapshot BDS is still alive?  What
>     happens when bdrv_snapshot_delete() is called while the BDS snapshot
>     exists?
>
> 2. At what level should resources like the bs->file and metadata caches
>     (L1/L2/refcount) be shared?  If they are shared it's easy to keep
>     them consistent but makes lifecycle handling harder.
>
> Stefan
>


-- 
Best Regards

Wenchao Xia

  reply	other threads:[~2013-07-19  9:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 14:03 [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd Wenchao Xia
2013-07-17 14:03 ` [Qemu-devel] [PATCH 1/4] snapshot: distinguish id and name in load_tmp Wenchao Xia
2013-07-17 14:03 ` [Qemu-devel] [PATCH 2/4] qemu-nbd: support internal snapshot export Wenchao Xia
2013-07-17 14:03 ` [Qemu-devel] [PATCH 3/4] qemu-nbd: add doc for " Wenchao Xia
2013-07-26  8:11   ` Stefan Hajnoczi
2013-07-29  1:57     ` Wenchao Xia
2013-07-29  7:39       ` Stefan Hajnoczi
2013-07-17 14:03 ` [Qemu-devel] [PATCH 4/4] qemu-iotests: add 057 internal snapshot export with qemu-nbd case Wenchao Xia
2013-07-17 14:23 ` [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd Eric Blake
2013-07-17 15:21   ` Kevin Wolf
2013-07-18  2:28     ` Wenchao Xia
2013-07-18  7:15       ` Fam Zheng
2013-07-19  6:29   ` Wenchao Xia
2013-07-19  8:20     ` Kevin Wolf
2013-07-22  5:20   ` Wenchao Xia
2013-07-18  5:43 ` Stefan Hajnoczi
2013-07-19  9:03   ` Wenchao Xia [this message]
2013-07-19  9:19     ` Kevin Wolf
2013-07-19 10:02       ` Wenchao Xia
2013-07-22  2:10     ` Fam Zheng
2013-07-22  3:26       ` Wenchao Xia
2013-07-25  2:30 ` Wenchao Xia
2013-07-25  8:06   ` Stefan Hajnoczi
2013-07-26  2:23     ` Wenchao Xia
2013-07-26  8:20       ` Stefan Hajnoczi
2013-07-29  2:05         ` Wenchao Xia

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=51E900D3.30705@linux.vnet.ibm.com \
    --to=xiawenc@linux.vnet.ibm.com \
    --cc=dietmar@proxmox.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.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.