From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9cNn-0004St-MK for qemu-devel@nongnu.org; Sat, 01 Feb 2014 10:21:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9cNh-0004nE-4W for qemu-devel@nongnu.org; Sat, 01 Feb 2014 10:21:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9cNg-0004n4-RV for qemu-devel@nongnu.org; Sat, 01 Feb 2014 10:21:17 -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 s11FLFQ5012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 1 Feb 2014 10:21:16 -0500 Date: Sat, 1 Feb 2014 23:21:17 +0800 From: Fam Zheng Message-ID: <20140201152117.GA6756@T430.redhat.com> References: <1390972061-26560-1-git-send-email-famz@redhat.com> <20140201030002.GB1023@gate.mains.priv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140201030002.GB1023@gate.mains.priv> Subject: Re: [Qemu-devel] [PATCH v13 00/14] Drop in_use from BlockDriverState and enable 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, armbru@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, stefanha@redhat.com, pbonzini@redhat.com On Fri, 01/31 19:00, Ian Main wrote: > On Wed, Jan 29, 2014 at 01:07:27PM +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 target). > > > > 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=RUNNING-VM.img to omit explicitly > > providing the size by ourselves, but it's risky because RUNNING-VM.qcow2 is > > used r/w by guest. Whether or not setting backing file in the image file > > doesn't matter, as we are going to override the backing hd in the next > > step) > > > > 2. (QMP) blockdev-add backing=source-drive file.driver=file file.filename=BACKUP.qcow2 id=target0 if=none driver=qcow2 > > It seems like we have a regression here. I sent you a private email > earlier and after some more testing I am finding that the setup that I > had to test this before is no longer working. Now when I try to use > blockdev-add I get: > > rsp = srv.cmd(command, {'options': { > 'backing': 'ide0-hd0', > 'driver': 'qcow2', > 'id': 'target0', > 'file': { > 'driver': 'file', > 'filename': '/home/imain/tmp/BACKUP.qcow2' > } > } > }) > > rsp is {u'error': {u'class': u'GenericError', u'desc': u"could not open > disk image target0: Block format 'qcow2' used by device 'target0' > doesn't support the option 'backing'"}} > > It's possible I'm messing something up but I'm pretty sure something has > changed with the options handling in bdrv_open() to make this not work > anymore. > My local test script is very similar to this, so as the case added in this series. They both work here. Have you found what is wrong there yet? Fam