From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjjag-0001x9-9Z for qemu-devel@nongnu.org; Fri, 22 Nov 2013 00:47:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjjaZ-0002PC-7U for qemu-devel@nongnu.org; Fri, 22 Nov 2013 00:47:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjjaY-0002Or-Uv for qemu-devel@nongnu.org; Fri, 22 Nov 2013 00:47:35 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAM5lXNq008670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Nov 2013 00:47:34 -0500 Message-ID: <528EEFEE.2060708@redhat.com> Date: Fri, 22 Nov 2013 13:47:26 +0800 From: Fam Zheng MIME-Version: 1.0 References: <1381988203-28576-1-git-send-email-famz@redhat.com> <20131120023218.GA9591@gate.mains.priv> In-Reply-To: <20131120023218.GA9591@gate.mains.priv> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v3 0/2] Point-in-time snapshot exporting over NBD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Main Cc: kwolf@redhat.com, hbrock@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, stefanha@redhat.com, pbonzini@redhat.com On 2013=E5=B9=B411=E6=9C=8820=E6=97=A5 10:32, Ian Main wrote: > On Thu, Oct 17, 2013 at 01:36:41PM +0800, Fam Zheng wrote: >> This series adds for point-in-time snapshot NBD exporting based on >> blockdev-backup (variant of drive-backup with existing device as targe= t). > > In general this seems to work great. I did a bunch of testing and was > able to mount filesystems over NBD, do many writes (on backed up > image)/reads (on target), intense IO etc and all held up fine. > > There are definitely some issues with some of the commands allowing you > to blow things up. I'm interested to hear opinions on whether this is = a > showstopper at this time or not. > Thanks very much for your testing, Ian. QEMU should report error instead=20 of crashing with invalid operations. I added an "operation blocker" and=20 incorporated into the next version. In the future, we still want to review more on those commands and try to=20 enable safe ones, and possibly also allow multiple block jobs on a BDS.=20 For now it is good enough to only allow blockdev-backup on the source=20 and NBD export on the target (which is safe, and all what we need for=20 image fleecing, as this version shows). With that being a working=20 implementation, I've posted v4. Please test and free to make comments. >> We get a thin point-in-time snapshot by COW mechanism of drive-backup,= and >> export it through built in NBD server. The steps are as below: >> >> 1. (SHELL) qemu-img create -f qcow2 BACKUP.qcow2 >> >> (Alternatively we can use -o backing_file=3DRUNNING-VM.img to omi= t explicitly >> providing the size by ourselves, but it's risky because RUNNING-V= M.qcow2 is >> used r/w by guest. Whether or not setting backing file in the ima= ge file >> doesn't matter, as we are going to override the backing hd in the= next >> step) >> >> 2. (QMP) blockdev-add backing=3Dsource-drive file.driver=3Dfile file= .filename=3DBACKUP.qcow2 id=3Dtarget0 if=3Dnone driver=3Dqcow2 > > I had to create a custom python script to make these commands work as > they require nested dicts. Is that normal or did I miss something > entirely? > Yes, I use a python script locally to test it too. Fam