From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rii1r-0005Tl-Mi for qemu-devel@nongnu.org; Thu, 05 Jan 2012 02:46:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rii1q-000706-Hn for qemu-devel@nongnu.org; Thu, 05 Jan 2012 02:46:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rii1q-0006zs-8b for qemu-devel@nongnu.org; Thu, 05 Jan 2012 02:46:26 -0500 Message-ID: <4F05554B.6090701@redhat.com> Date: Thu, 05 Jan 2012 08:46:19 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20120104140854.631720304@redhat.com> <20120104140945.618799948@redhat.com> <4F0477FE.3000801@redhat.com> <20120104174724.GA21596@amt.cnet> <4F049462.50406@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch 3/4] block stream: add support for partial streaming List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, Marcelo Tosatti , Eric Blake , stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org 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 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