From: Paolo Bonzini <pbonzini@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: kwolf@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: Thu, 05 Jan 2012 08:46:19 +0100 [thread overview]
Message-ID: <4F05554B.6090701@redhat.com> (raw)
In-Reply-To: <CAJSP0QUU4U_YEHGPY-Yc-86iw4JuAfKDh3b2KMi-fnukpDu7qw@mail.gmail.com>
On 01/04/2012 11:40 PM, Stefan Hajnoczi wrote:
> 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
>
> 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.
That makes sense, just like most qemu-img commands have an equivalent in
the monitor for online usage.
> Paolo: I haven't looked at the new and improved NBD server yet. Does
> this sound doable?
Yes, indeed. It should not be hard. The NBD server is now entirely
asynchronous, and by using the main loop the integration is very much
simplified.
Briefly, nbd.c now has a simple server API:
typedef struct NBDExport NBDExport;
typedef struct NBDClient NBDClient;
NBDExport *nbd_export_new(BlockDriverState *bs, off_t dev_offset,
off_t size, uint32_t nbdflags);
void nbd_export_close(NBDExport *exp);
NBDClient *nbd_client_new(NBDExport *exp, int csock,
void (*close)(NBDClient *));
... that takes care of everything except creating the server socket and
accepting clients from it. Which is actually even better, because
instead of having a generic NBD server you could start one on a file
descriptor that you pass via SCM_RIGHTS (aka getfd).
> 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?
We can prevent closing the parent BDS until all its children are gone.
Paolo
next prev parent reply other threads:[~2012-01-05 7:46 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 [this message]
2012-01-09 10:58 ` Kevin Wolf
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=4F05554B.6090701@redhat.com \
--to=pbonzini@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mtosatti@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).