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 <source size here>
> >
> > (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
