qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [patch 3/4] block stream: add support for partial strea


From: Kevin Wolf
Subject: Re: [Qemu-devel] [patch 3/4] block stream: add support for partial streaming
Date: Mon, 09 Jan 2012 11:58:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

Am 04.01.2012 23:40, schrieb Stefan Hajnoczi:
> The qcow2 implementation never accesses snapshots directly.  Instead
> there's the concept of the current L1 table, which means there is a
> single global state of the disk.  Snapshots are immutable and are
> never accessed directly, only copied into the current L1 table.  The
> single global state makes it a little tricky to access a snapshot
> while the VM is running.
> 
> That said, the file format itself doesn't prevent an implementation
> from supporting read-only access to snapshots.  In theory we can
> extend the qcow2 implementation to support this behavior.

And I think in practice we should. I've been meaning to do something
like this for too long, but as you know everyone is focussed on external
snapshots, so the internal ones don't get the attention they would deserve.

> What you want sounds almost like an NBD server that can be
> launched/stopped while qemu is already running a VM.  This could be a
> QEMU monitor command like:
> nbd-start tcp::1234 virtio-disk0 --snapshot 20120104

I like this idea. :-)

> It would be possible to stop the server using the same <socket, drive,
> snapshot> tuple.  Note the server needs to provide read-only access,
> allowing writes probably has little use and people will hose their
> data.
> 
> Paolo: I haven't looked at the new and improved NBD server yet.  Does
> this sound doable?
> 
> Kevin: I think we need something like qcow2_snapshot_load_tmp() but it
> returns a full new BlockDriverState.  The hard thing is that duping a
> read-only snapshot qcow2 state leads to sharing and lifecycle problems
> - what if we want to close the original BlockDriverState, will the
> read-only snapshot state prevent this?

Yes, creating new read-only BlockDriverStates from one image is exactly
the thought that I had when reading this thread. The problem is that the
BlockDriverStates wouldn't be fully independent. What if you delete the
snapshot that is used by another BlockDriverState etc.?

I think the least you would need is to have a separation between one
BlockImage (which is a whole qcow2 file) and multiple BlockDriverStates
(which is the backend that devices/NBD servers/whatever use). Not sure
if such a fundamental block layer change is worth the effort. On the
other hand, if Anthony is serious about QOM we'll get a fundamental
design change anyway at some point...

Kevin



reply via email to

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