Description of problem: "qemu-img info" hangs to get information of the NBD disk image which is in use Version-Release number of selected component (if applicable): Host kernel: 3.10.0-797.el7.ppc64le Guest kernel: 3.10.0-797.el7.ppc64le qemu-kvm-rhev: qemu-kvm-rhev-2.10.0-8.el7 How reproducible: 100% Steps to Reproduce: 1. Export an image file on NBD server side # qemu-img create -f qcow2 -o preallocation=full /home/nbd_dataimage_0.qcow2 1G # qemu-nbd -f raw /home/nbd_dataimage_0.qcow2 -p 9000 -t & 2. On NBD client side, get info of this NBD image # qemu-img info nbd:10.16.69.87:9000 image: nbd://10.16.69.87:9000 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: unavailable cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false 3. Boot up one guest, and use the above NBD image as one data disk -device virtio-scsi-pci,bus=pci.0,id=scsi1 \ -drive file=nbd:10.16.69.87:9000,if=none,cache=none,id=drive_ddisk_2,format=qcow2,werror=stop,rerror=stop \ -device scsi-hd,drive=drive_ddisk_2,bus=scsi1.0,id=ddisk_2 \ 4. Get info of this NBD image again # qemu-img info nbd:10.16.69.87:9000 Actual results: qemu-img hangs in step4 Expected results: qemu-img should return instead of hang Additional info: x86 also has this problem Host kernel: 3.10.0-799.el7.x86_64 qemu-kvm-rhev: qemu-kvm-rhev-2.10.0-9.el7
This is a fundamental limitation of the NBD protocol - only the server can control whether an image is read-only or read-write, and it is up to the server to decide how many simultaneous read-write connections are permitted (in qemu's case, at most 1). So as long as there is a read-write client connected to the server, no other client can connect read-only. That said, I think this may be worth an extension to the NBD protocol to permit a client to inform the server that it only wants a read-only connection; at which point the server can be enhanced to allow read-only clients in parallel with a read-write client, so that qemu-img info could "work" for such an enhanced server (note that "work" is a relative term - just as with file op-blockers, you can't trust a read-only connection to always be consistent with regards to guest-visible contents is the writing client is in the middle of making modifications). I'll propose the idea upstream, and see what the NBD community thinks.
Extension proposal: https://lists.debian.org/nbd/2017/nbd-201711/msg00046.html While writing that up, I note that qemu's current implementation does not even bother to allow parallel connections (where secondary connections are marked NBD_FLAG_READ_ONLY), which is possible even without the extension; so there is certainly room for improvement in upstream qemu regardless of what upstream NBD says.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
hi, I verified the behavior of the steps documented above and it's still the same as described. Qemu version: qemu-kvm-5.1.0-10.module+el8.3.0+8254+568ca30d kernel-4.18.0-234 The qemu-nbd info still hangs after qemu is booted with the nbd image.
Reproduce this bug with qemu-img-5.1.0-13.module+el8.3.0+8382+afc3bbea.x86_64, the issue still exists. Version: qemu-img-5.1.0-13.module+el8.3.0+8382+afc3bbea.x86_64 kernel-4.18.0-240.el8.x86_64 Steps: 1. Export an image file on NBD server side # qemu-img create -f qcow2 -o preallocation=full /home/nbd_dataimage_0.qcow2 1G # qemu-nbd -f raw /home/nbd_dataimage_0.qcow2 -p 9000 -t & 2. On NBD client side, get info of this NBD image # qemu-img info nbd:localhost:9000 3. Boot up one guest, and use the above NBD image as one data disk 4. Get info of this NBD image again # qemu-img info nbd:localhost:9000 Actual results: qemu-img hangs in step4 Expected results: qemu-img should return instead of hang
This issue cannot be reproduced if exporting nbd image with -e parameter. -e, --shared=NUM device can be shared by NUM clients (default '1') Without -e option, booted guest is the only one allowed client to access the nbd image, is this the reason that host cannot get nbd image info? Should cmd # qemu-img info nbd:localhost:9000 fails and returns the error message something like permission denied. Version: qemu-img-5.1.0-13.module+el8.3.0+8382+afc3bbea.x86_64 kernel-4.18.0-240.el8.x86_64 Steps: 1. Export an image file on NBD server side, add a para which allows 3 clients to access this image. # qemu-img create -f qcow2 -o preallocation=full /home/nbd_dataimage_0.qcow2 1G # qemu-nbd -f raw /home/nbd_dataimage_0.qcow2 -e 3 -p 9000 -t & 2. On NBD client side, get info of this NBD image # qemu-img info nbd:localhost:9000 3. Boot up one guest, and use the above NBD image as one data disk 4. Get info of this NBD image again # qemu-img info nbd:localhost:9000 Actual Result: Image info shows with no errors. Expected result: Same as above Addtional info: -e, --shared=NUM device can be shared by NUM clients (default '1') Without -e para
Based on Eric's comment #Comment 2 , I think it's the expected behavior. The feature has not been implemented yet, and it is an NBD limitation. If you set the shared flag to 1 (as the default value), you obtain the same behavior. In my case: # ./qemu-nbd -f raw /tmp/nbd_dataimage_0.qcow2 -e 1 -p 9000 -t Boot qemu with the NBD image # ./qemu-img info nbd:localhost:9000 Hang In the case of -e 3, I guess you can have up to 3 shared clients, and I think it'll start hanging from 4 connections.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
This issue can still be reproduced on qemu-kvm-5.2.0-1.module+el8.4.0+9091+650b220a.x86_64, as it is a future feature, QA agrees to close this bug.