qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd
Date: Thu, 18 Jul 2013 13:43:50 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

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().

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]