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
pgpBk1Hy0_VaE.pgp
Description: PGP signature