Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
host info:
# uname -r && rpm -q qemu-kvm
3.6.0-0.29.el7.x86_64
qemu-kvm-1.3.0-3.el7.x86_64
guest info
# uname -r
3.6.0-0.29.el7.x86_64
Steps:
1. boot up guest with a readonly=on data image with snapshot=on.
e.g:...-drive file=/home/my-data-disk.qcow2,if=none,format=qcow2,id=drive-virtio0-0-0,media=disk,cache=none,readonly=on,snapshot=on -device virtio-blk-pci,bus=pci.0,addr=0x8,drive=drive-virtio0-0-0,id=virtio0-0-0
2. dd a file in the guest to the data disk.
3. do commit in monitor.
(qemu) info block
drive-system-disk: removable=0 io-status=ok file=/home/RHEL-7-Server-x86_64.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
drive-virtio0-0-0: removable=0 io-status=ok file=/tmp/vl.jpdcow backing_file=/home/my-data-disk.qcow2 backing_file_depth=1 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
floppy0: removable=1 locked=0 tray-open=0 [not inserted]
sd0: removable=1 locked=0 tray-open=0 [not inserted]
(qemu) ? commit
commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files
(qemu) commit drive-virtio0-0-0
Expected result:
should fail to commit to a read-only disk with an error message prompts mentioned that backing image is read-only.
(In reply to comment #1)
>
> Expected result:
> should fail to commit to a read-only disk with an error message prompts
> mentioned that backing image is read-only.
check the data disk size and modify time in host, but there is no any changes before and after commit.
- before step 1:
# ls -l /home/my-data-disk.qcow2
-rw-r--r--. 1 root root 8725790720 Jan 10 11:09 /home/my-data-disk.qcow2
- after step 3:
# ls -l /home/my-data-disk.qcow2
-rw-r--r--. 1 root root 8725790720 Jan 10 11:09 /home/my-data-disk.qcow2
For completeness, from BZ #856505:
In bdrv_commit(), we are (appropriately) refusing to write to the backing file (in this case, the top-level snapshot, as the active layer is a temp image). The function bdrv_reopen() returns an error, and bdrv_commit() returns -EACCES.
However, do_commit(), which is the message handler that calls bdrv_commit(), only checks for -EBUSY when it comes to returning an error message.