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.
It turns out this issue is a bit more complex than just an incorrect error message. This started to occur after commit f0d6b82: 'block: Produce zeros when protocols reading beyond end of file'.
In that commit, rather than always calling the driver bdrv_co_readv() method, the length is checked by a call to bdrv_getlength(), and the number of sectors computed. If there are 0 sectors in the BDS file, the read is short circuited and the function returns success.
When using a blkdebug filter, the initial length as recorded in the BDS is 0 after bdrv_open().
bdrv_getlength() will call the driver .bdrv_getlength() method, however in the current codebase the blkdebug driver did not have a .bdrv_getlength() method.
The solution is to backport commit e130225587cb0d48b2c0b7c04b6bf9c95fe75ac9: 'blkdebug: pass getlength to underlying file', which implements .bdrv_getlength() by passing it along to its underlying file format.
This will manifest itself also by incorrectly identifying the file as 'raw' rather than 'qcow2':
./qemu-img info blkdebug:blkdebug.cfg:blkdebug.qcow2
image: blkdebug:blkdebug.cfg:blkdebug.qcow2
file format: raw
virtual size: 0 (0 bytes)
disk size: 260K
After the fix (backport of e130225):
./qemu-img info blkdebug:blkdebug.cfg:blkdebug.qcow2
image: blkdebug:blkdebug.cfg:blkdebug.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 260K
cluster_size: 512
Comment 14Miroslav Rezanina
2014-04-29 06:01:33 UTC
Verified on qemu-kvm-rhev-0.12.1.2-2.427.el6.x86_64:
with steps in comment 0, after step 4:
qemu-io> write -b 0 1G
write failed: Operation not permitted
Verified.
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.
http://rhn.redhat.com/errata/RHBA-2014-1490.html