This was already fixed in upstream 3.1, so we got the fix automatically with the rebase.

 Sorry, I looked up the wrong patch. This is indeed missing, so resetting the status.

Martin, can you grant PM+ please?

Thank you

Fix included in qemu-kvm-3.1.0-17.module+el8+2831+8d13a174

Verify it on qemu-kvm-3.1.0-18.module+el8+2834+fa8bb6e2.x86_64, it also has the same issue with RHEL7(BZ#1667320).
  
  Start vm failed with auto-read-only=on with info: qemu-kvm: -blockdev driver=qcow2,file=file_base,node-name=base,auto-read-only=on: Block node is read-only

  But when we start vm with read-only=on, it success.


aliang

Test on qemu-kvm-3.1.0-18.module+el8+2834+fa8bb6e2.x86_64, detail as bellow:
  Test steps:
    1. Start vm with base raw format on https server and auto-read-only=on.
        -blockdev node-name=file_base,driver=https,sslverify=off,url=https://10.66.144.33/base,auto-read-only=on \
        -blockdev driver=raw,file=file_base,node-name=base,auto-read-only=on \
        -blockdev driver=file,node-name=file_sn1,filename=/home/sn1,auto-read-only=on \
        -blockdev driver=qcow2,file=file_sn1,node-name=sn1,auto-read-only=on,backing=base \
        -blockdev driver=file,node-name=file_sn2,filename=/home/sn2,auto-read-only=on \
        -blockdev driver=qcow2,file=file_sn2,node-name=sn2,backing=sn1,auto-read-only=on \
        -blockdev driver=file,node-name=file_sn3,filename=/home/sn3 \
        -blockdev driver=qcow2,file=file_sn3,node-name=sn3,backing=sn2 \
 
    2. Do block commit from sn2 to sn1.
        {'execute': 'block-commit', 'arguments': { 'device':'sn3','base-node':'sn1','top-node':'sn2','job-id':'j1'}}
{"timestamp": {"seconds": 1551840222, "microseconds": 67119}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "j1"}}
{"timestamp": {"seconds": 1551840222, "microseconds": 67586}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "j1"}}
{"return": {}}
{"timestamp": {"seconds": 1551840222, "microseconds": 84841}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "j1"}}
{"timestamp": {"seconds": 1551840222, "microseconds": 84875}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "j1"}}
{"timestamp": {"seconds": 1551840222, "microseconds": 85161}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "j1", "len": 1073741824, "offset": 1073741824, "speed": 0, "type": "commit"}}
{"timestamp": {"seconds": 1551840222, "microseconds": 85197}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "j1"}}
{"timestamp": {"seconds": 1551840222, "microseconds": 85220}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "j1"}}

     3. Shutdown vm, then start it with a qcow2 image on https server, but read-only=on set on its format node.
        -blockdev node-name=file_base,driver=https,sslverify=off,url=https://10.66.144.33/base,auto-read-only=on \
        -blockdev driver=qcow2,file=file_base,node-name=base,read-only=on \
        -blockdev driver=file,node-name=file_sn1,filename=/home/sn1,auto-read-only=on \
        -blockdev driver=qcow2,file=file_sn1,node-name=sn1,auto-read-only=on,backing=base \
        -blockdev driver=file,node-name=file_sn2,filename=/home/sn2,auto-read-only=on \
        -blockdev driver=qcow2,file=file_sn2,node-name=sn2,backing=sn1,auto-read-only=on \
        -blockdev driver=file,node-name=file_sn3,filename=/home/sn3 \
        -blockdev driver=qcow2,file=file_sn3,node-name=sn3,backing=sn2 \

       block_commit can also executed successfully.

     4. Shutdown vm, then start it with qcow2 image on https server and "auto-read-only=on" set on its format node.
        -blockdev node-name=file_base,driver=https,sslverify=off,url=https://10.66.144.33/base,auto-read-only=on \
        -blockdev driver=qcow2,file=file_base,node-name=base,auto-read-only=on \

        VM failed to start, with info:
          qemu-kvm: -blockdev driver=qcow2,file=file_base,node-name=base,auto-read-only=on: Block node is read-only

 Will set this bug's status to "Verified" and track the issue in step4 by BZ#1685777.

Cancel the needinfo, for reply had received in BZ#1667320.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:1293

*** Bug 1717165 has been marked as a duplicate of this bug. ***