Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1518543

Summary: "qemu-img info" hangs to get information of the NBD disk image which is in use
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: yilzhang
Component: qemu-kvmAssignee: Eric Blake <eblake>
Status: ASSIGNED --- QA Contact: Tingting Mao <timao>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: coli, eblake, knoel, lolyu, michen, ngu, pingl, qzhang, rbalakri, virt-maint
Target Milestone: rcKeywords: FutureFeature
Target Release: 8.0   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description yilzhang 2017-11-29 07:16:20 UTC
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:
image: nbd://
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:,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:

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

Comment 2 Eric Blake 2017-11-29 13:59:02 UTC
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.

Comment 3 Eric Blake 2017-11-29 16:00:22 UTC
Extension proposal:

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.