Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs

[Kevin Wolf]

Am 03.04.2017 um 14:51 hat Peter Krempa geschrieben:
> On Mon, Apr 03, 2017 at 10:15:42 +0200, Kevin Wolf wrote:
> > Am 31.03.2017 um 19:43 hat Max Reitz geschrieben:
> > > On 31.03.2017 18:03, Ciprian Barbu wrote:
> 
> [...]
> 
> > > So this doesn't work:
> > > 
> > > $ x86_64-softmmu/qemu-system-x86_64 \
> > >     -blockdev node-name=image,driver=qcow2,\
> > > file.driver=file,file.filename=foo.qcow2 \
> > >     -device virtio-blk,drive=image \
> > >     -qmp stdio
> > > {"QMP": {"version": {"qemu": {"micro": 92, "minor": 8, "major": 2},
> > > "package": " (v2.8.0-2038-g6604c893d0)"}, "capabilities": []}}
> > > {'execute':'qmp_capabilities'}
> > > {"return": {}}
> > > {'execute':'nbd-server-start','arguments':{'addr':{'type':'inet','data':{'host':'localhost','port':'10809'}}}}
> > > {"return": {}}
> > > {'execute':'nbd-server-add','arguments':{'device':'image','writable':true}}
> > > {"error": {"class": "GenericError", "desc": "Conflicts with use by
> > > /machine/peripheral-anon/device[0]/virtio-backend as 'root', which does
> > > not allow 'write' on image"}
> > > 
> > > But this works:
> > > 
> > > $ x86_64-softmmu/qemu-system-x86_64 \
> > >     -blockdev node-name=image,driver=qcow2,\
> > > file.driver=file,file.filename=foo.qcow2 \
> > >     -device virtio-blk,drive=image,share-rw=on \
> > >     -qmp stdio
> > > {"QMP": {"version": {"qemu": {"micro": 92, "minor": 8, "major": 2},
> > > "package": " (v2.8.0-2038-g6604c893d0)"}, "capabilities": []}}
> > > {'execute':'qmp_capabilities'}
> > > {"return": {}}
> > > {'execute':'nbd-server-start','arguments':{'addr':{'type':'inet','data':{'host':'localhost','port':'10809'}}}}
> > > {"return": {}}
> > > {'execute':'nbd-server-add','arguments':{'device':'image','writable':true}}
> > > {"return": {}}
> > > 
> > > (The difference is the share-rw=on in the -device parameter.)
> > > 
> > > So in theory all that's necessary is to set share-rw=on for the device
> > > in the management layer. But I'm not sure whether that's practical.
> > 
> > Yes, libvirt needs to provide this option if the guest supports sharing.
> > If it doesn't support sharing, rejecting a read-write NBD client seems
> > correct to me.
> > 
> > Peter, Eric, what is the status on the libvirt side here?
> 
> Libvirt currently uses the NBD server only for non-shared storage
> migration. At that point the disk is not shared (while qemu may think
> so) since the other side is not actually running until the mirror
> reaches synchronized state.

Yes, I misunderstood the situation at first.

Anyway, is there already a libvirt patch for the cases where the image
is actually shared?

Kevin

pgpzp0aMgRrFE.pgp
Description: PGP signature