From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9lci-00061F-7X for qemu-devel@nongnu.org; Sat, 01 Feb 2014 20:13:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9lcc-0001Mk-45 for qemu-devel@nongnu.org; Sat, 01 Feb 2014 20:13:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9lcb-0001Mg-Qg for qemu-devel@nongnu.org; Sat, 01 Feb 2014 20:13:18 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s121DGYa031394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 1 Feb 2014 20:13:17 -0500 Date: Sat, 1 Feb 2014 17:13:11 -0800 From: Ian Main Message-ID: <20140202011310.GD1023@gate.mains.priv> References: <1390972061-26560-1-git-send-email-famz@redhat.com> <20140201030002.GB1023@gate.mains.priv> <20140201152117.GA6756@T430.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140201152117.GA6756@T430.redhat.com> 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: Fam Zheng Cc: kwolf@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, stefanha@redhat.com, pbonzini@redhat.com On Sat, Feb 01, 2014 at 11:21:17PM +0800, Fam Zheng wrote: > 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? Hrrm, so I cleaned up my tree, pulled to latest and applied these and it worked. Not sure what happened there but it all seems good now. I should have tried that before I posted. Ian