qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [patch 3/4] block stream: add support for partial streaming
Date: Mon, 09 Jan 2012 11:58:20 +0100	[thread overview]
Message-ID: <4F0AC84C.10406@redhat.com> (raw)
In-Reply-To: <CAJSP0QUU4U_YEHGPY-Yc-86iw4JuAfKDh3b2KMi-fnukpDu7qw@mail.gmail.com>

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

  parent reply	other threads:[~2012-01-09 10:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-30 10:03 [Qemu-devel] [patch 0/5] block streaming base support Marcelo Tosatti
2011-12-30 10:03 ` [Qemu-devel] [patch 1/5] block: add bdrv_find_backing_image Marcelo Tosatti
2011-12-30 10:03 ` [Qemu-devel] [patch 2/5] block: implement bdrv_find_backing_image in qcow2 Marcelo Tosatti
2012-01-03 13:44   ` Stefan Hajnoczi
2011-12-30 10:03 ` [Qemu-devel] [patch 3/5] add QERR_BASE_ID_NOT_FOUND Marcelo Tosatti
2011-12-30 10:03 ` [Qemu-devel] [patch 4/5] block stream: add support for partial streaming Marcelo Tosatti
2012-01-04 12:39   ` Stefan Hajnoczi
2012-01-04 13:52     ` Marcelo Tosatti
2011-12-30 10:03 ` [Qemu-devel] [patch 5/5] add doc to describe live block operations Marcelo Tosatti
2012-01-04 14:08 ` [Qemu-devel] [patch 0/4] block streaming base support (v2) Marcelo Tosatti
2012-01-04 14:08   ` [Qemu-devel] [patch 1/4] block: add bdrv_find_backing_image Marcelo Tosatti
2012-01-04 14:08   ` [Qemu-devel] [patch 2/4] add QERR_BASE_ID_NOT_FOUND Marcelo Tosatti
2012-01-04 14:08   ` [Qemu-devel] [patch 3/4] block stream: add support for partial streaming Marcelo Tosatti
2012-01-04 16:02     ` Eric Blake
2012-01-04 17:47       ` Marcelo Tosatti
2012-01-04 18:03         ` Eric Blake
2012-01-04 19:22           ` Marcelo Tosatti
2012-01-04 22:40           ` Stefan Hajnoczi
2012-01-05  7:46             ` Paolo Bonzini
2012-01-09 10:58             ` Kevin Wolf [this message]
2012-01-09 13:14               ` Stefan Hajnoczi
2012-01-04 14:08   ` [Qemu-devel] [patch 4/4] add doc to describe live block operations Marcelo Tosatti

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=4F0AC84C.10406@redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.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).