From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzTYL-0007nu-Ud for qemu-devel@nongnu.org; Wed, 17 Jul 2013 11:22:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzTYG-0005z0-Ab for qemu-devel@nongnu.org; Wed, 17 Jul 2013 11:22:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzTYG-0005yu-1U for qemu-devel@nongnu.org; Wed, 17 Jul 2013 11:22:00 -0400 Date: Wed, 17 Jul 2013 17:21:49 +0200 From: Kevin Wolf Message-ID: <20130717152149.GN2458@dhcp-200-207.str.redhat.com> References: <1374069835-14287-1-git-send-email-xiawenc@linux.vnet.ibm.com> <51E6A8D3.4050406@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E6A8D3.4050406@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: pbonzini@redhat.com, stefanha@redhat.com, Wenchao Xia , dietmar@proxmox.com, qemu-devel@nongnu.org Am 17.07.2013 um 16:23 hat Eric Blake geschrieben: > On 07/17/2013 08:03 AM, 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. > > > > This brings two interesting issues: > > 1 is it safe to let qemu-nbd and qemu access that file at same time? > > Probably not, for the same reason we tell people to not use qemu-img > while qemu is active on a file. No, it's not. There's the built-in NBD server, but making internal snapshots usable with it would require some non-trivial changes in the block layer and the qcow2 code. > > I think it is safe, since qemu-nbd is read only. The data will be correct from > > qemu-nbd, if qemu does not delete that snapshot when qemu-nbd is running, and > > data is flushed to storage after qemu take that snapshot so that qemu-nbd > > would see the correct data. > > You're making assumptions that qemu won't be touching any metadata in a > manner in which the read-only qemu-nbd could get confused; I'm not sure > we are ready to make that guarantee. I think the export has to be from > the running qemu process itself, rather than from a second process. I think a while ago I convinced myself that in practice it does work, but it's not a guarantee we're making and I won't hesitate to break the assumption if it's helpful for some feature. > > 2 should an nbd-server exporting internal snapshot be added in qemu? > > I think no. Compared with driver-backup, the snapshot, or COW happens > > in storage level, so it allows another program to read it itself. Actually > > it should be OK to let another server other than qemu's host, do the > > export I/O job, if data is flushed. > > Unfortunately, I disagree, and think the answer to this question is yes, > we need to do the export from within the single qemu process, if we want > to guarantee safety. Agreed. Kevin