Bug 1667320 - -blockdev: auto-read-only is ineffective for drivers on read-only whitelist
Summary: -blockdev: auto-read-only is ineffective for drivers on read-only whitelist
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: aihua liang
Depends On:
Blocks: 1678968 1717165
TreeView+ depends on / blocked
Reported: 2019-01-18 07:26 UTC by aihua liang
Modified: 2019-08-22 09:20 UTC (History)
4 users (show)

Fixed In Version: qemu-kvm-rhev-2.12.0-24.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1678968 1717165 (view as bug list)
Last Closed: 2019-08-22 09:19:59 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2553 None None None 2019-08-22 09:20:49 UTC

Description aihua liang 2019-01-18 07:26:35 UTC
Description of problem:
 Curl can't support auto-read-only well

Version-Release number of selected component (if applicable):
  kernel version:3.10.0-957.1.3.el7.x86_64
  qemu-kvm-rhev version:qemu-kvm-rhev-2.12.0-18.el7_6.3.x86_64

How reproducible:

Steps to Reproduce:
 driver: https
        step1: create 3 images
         (https server)# qemu-img create -f qcow2 base 1G
         # qemu-img create -f qcow2 /home/atest/sn1 1G
         # qemu-img create -f qcow2 /home/atest/sn2 1G
        step2: start qemu with snapshot chain: base->sn1->sn2
         -blockdev node-name=file_base,driver=https,sslverify=off,url=,auto-read-only=on \
         -blockdev driver=qcow2,file=file_base,node-name=base,auto-read-only=on \
         -blockdev driver=file,node-name=file_sn1,filename=/home/atest/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/atest/sn2 \
         -blockdev driver=qcow2,file=file_sn2,node-name=sn2,backing=sn1 \

    test result:
         qemu-kvm: -blockdev driver=https,node-name=file_base,sslverify=off,url=,auto-read-only=on: Driver 'https' can only be used for read-only devices

     driver: http
      test steps:
        step1: same as step1 above
        step2: start qemu with snapshot chain: base->sn1->sn2
         -blockdev node-name=file_base,driver=http,url=,read-only=on \
         -blockdev driver=qcow2,file=file_base,node-name=base,read-only=on \
         -blockdev driver=file,node-name=file_sn1,filename=/home/atest/sn1,read-only=on \
         -blockdev driver=qcow2,file=file_sn1,node-name=sn1,read-only=on,backing=base \
         -blockdev driver=file,node-name=file_sn2,filename=/home/atest/sn2 \
         -blockdev driver=qcow2,file=file_sn2,node-name=sn2,backing=sn1 \
      test result:
         qemu start failed with info:
           qemu-kvm: -blockdev driver=http,node-name=file_base,url=,read-only=on: Driver 'http' is not whitelisted
         when check img info via http success:
           qemu-img info 'json:{"file.driver":"http", "file.url":""}
           > '
             image: json:{"driver": "qcow2", "file": {"url": "", "driver": "http"}}
             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

Comment 3 Kevin Wolf 2019-01-18 09:33:24 UTC
Thanks, I can see the problem. If the driver whitelist check fails for read-write, but the driver is on the read-only whitelist, we forget to check whether we can use auto-read-only to downgrade to read-only.

Comment 4 aihua liang 2019-01-22 02:37:51 UTC
Same problem also exist in qemu-kvm-rhev-2.12.0-21.el7.x86_64.

Comment 7 Miroslav Rezanina 2019-02-26 11:24:56 UTC
Fix included in qemu-kvm-rhev-2.12.0-24.el7

Comment 12 aihua liang 2019-03-06 02:24:44 UTC
Test on qemu-kvm-rhev-2.12.0-24.el7.x86_64, it works ok with base's file node format "raw":
  -blockdev node-name=file_base,driver=https,sslverify=off,url=,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 \

 {'execute': 'block-commit', 'arguments': { 'device':'sn3','base-node':'sn1','top-node':'sn2','job-id':'j1'}}
{"timestamp": {"seconds": 1551837774, "microseconds": 533141}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "j1"}}
{"timestamp": {"seconds": 1551837774, "microseconds": 533344}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "j1"}}
{"return": {}}
{"timestamp": {"seconds": 1551837774, "microseconds": 562099}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "j1"}}
{"timestamp": {"seconds": 1551837774, "microseconds": 562144}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "j1"}}
{"timestamp": {"seconds": 1551837774, "microseconds": 562510}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "j1", "len": 1073741824, "offset": 1073741824, "speed": 0, "type": "commit"}}
{"timestamp": {"seconds": 1551837774, "microseconds": 562562}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "j1"}}
{"timestamp": {"seconds": 1551837774, "microseconds": 562601}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "j1"}}

  But when i test it with base's file node format "qcow2", failed to start vm with info:
    qemu-kvm: -blockdev driver=qcow2,file=file_base,node-name=base,auto-read-only=on: Block node is read-only

  I'll track the issue by BZ#1685772 and set this bug's status to "Verified".

Comment 14 errata-xmlrpc 2019-08-22 09:19:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.