Bug 439279

While the internal QEMU block drivers have a concept of a 'read only' disk, they
only set the read-only flag if the underlying file/device permissions are
read-only. There's no way to set it based on the Xen configuration. XenStore has
the neccessary info, so its primarily an issue of passing the read-only flag
down into the backend driver.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Created attachment 311567 [details]
Pass readonly flag through to QEMU block backend drivers

This is a proof of concept patch to make QEMU's block driver honour the
read-only flag on block devices.

Upstream rejected this patch and want a completely different approach to dealing with this problem. I very much doubt I'll get a re-written patch that's suitable for upstream, in time for RHEL-5.3, so we'll probably have to re-target this for 5.4

Still no upstream agreement on this, so putting back to ASSIGNED.

(In reply to comment #6)
> Still no upstream agreement on this, so putting back to ASSIGNED.    

It appears that upstream doesn't have the fix done this way if it has some read-only file handling applied at all. Unfortunately, I can't still even boot xen-unstable because of some kernel panic. Although if there is no upstream agreement I think we may apply this fix since the code-base is different. Unfortunately, like stated, I can't even boot the upstream xen-unstable to confirm it's still an issue here.

Michal

Created attachment 419450 [details]
Fix to make HVM guests honor the read-only flag

Hi,
this is the patch to fix the read-only image file handling since the image file was always treated as read-write which means that all the HVM guests were able to write to all the disk images available in domain configuration file no matter what the mode of the image was defined. This patch fixes this functionality to honor the O_RDONLY in the BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI interfaces that uses it.

It's been tested on RHEL-5 x86_64 dom0 and with this patch applied I was able to write to a read-write disk but not to read-only disk so it was working fine.

Just a note: when you want to mount an image that is set as read-only in the domain configuration file but you omit to set mode to read-only it results into I/O errors when processing the requests. Remounting as read-only or unmounting and remounting using the `mount /dev/* /path/to/mount -o ro` shall do the mounting the correct way, i.e. with no I/O errors, so make sure you mount those disks as read-only otherwise you can be getting errors like:

end_request: I/O error, dev hdb, sector 52
Buffer I/O error on device hdb1, logical block 1
lost page write due to I/O error on hdb1

and for IDE devices you'll be getting several additional DeviceFault errors since mounting the device read-write (default setting) writes some data onto a disk at the mount-time. 

For SCSI devices the DATA PROTECT request sense has been added
as found at: http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command

The very same patch has been send upstream for review.

Michal

Created attachment 426287 [details]
Fix to make HVM guests honor the read-only flag v4

This is the new patch to also allow read-only IDE CD-ROM drives since they should be allowed according to the specifications.

Michal

I also added a technical comments which should be added as release notes since this is the new feature implemented.

Michal

Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
For new guest creation the read-only IDE disks will be prohibited and the guest will refuse to start but for migrations and restores from the older version of Xen the old (incorrect) behaviour will be preserved which means that the guest could be restored or migrated successfully.

Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1,3 @@
-For new guest creation the read-only IDE disks will be prohibited and the guest will refuse to start but for migrations and restores from the older version of Xen the old (incorrect) behaviour will be preserved which means that the guest could be restored or migrated successfully.+Previous versions of Xen allowed the creation of read-only emulated disks (IDE or SCSI), but ignored the read-only attribute and let the guest write to the disk.  Starting with RHEL 5.6, SCSI disks will properly report the read-only bit, while read-only IDE disks are not allowed---in the presence of such a configuration, the guest will refuse to start.
+
+Migrations and restores of guests started under older version of Xen have a different behavior to avoid backward incompatibility.  SCSI disks will start reporting write errors after successful restore or migration, while for IDE disks the old (incorrect) behaviour will be preserved.

Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,3 +1,3 @@
-Previous versions of Xen allowed the creation of read-only emulated disks (IDE or SCSI), but ignored the read-only attribute and let the guest write to the disk.  Starting with RHEL 5.6, SCSI disks will properly report the read-only bit, while read-only IDE disks are not allowed---in the presence of such a configuration, the guest will refuse to start.
+For fully-virtualized Xen guests, Previous versions of RHEL allowed the creation of read-only emulated disks (IDE or SCSI), but ignored the read-only attribute and let the guest write to the disk.  Starting with RHEL 5.6, SCSI disks will properly report the read-only bit, while read-only IDE disks are not allowed---in the presence of such a configuration, the guest will refuse to start.
 
 Migrations and restores of guests started under older version of Xen have a different behavior to avoid backward incompatibility.  SCSI disks will start reporting write errors after successful restore or migration, while for IDE disks the old (incorrect) behaviour will be preserved.

Created attachment 435010 [details]
Patch v5

Well, this is the new version of the patch implementing the silent change of read-only IDE disk flag to read-write flag on restore/migrate when the HVM guest was using the read-only IDE disk. Basically using the read-only IDE disk is basically a misconfiguration since it's not supported by specifications.

Michal

Created attachment 449921 [details]
scsi disk ro after restored from xen-115

Created attachment 449922 [details]
scsi disk ro newly created on xen-116

I tried with rhel6 64bit guest.

1. Create rhel6 HVM guest1  with IDE read-only on xen-115 build without the fix. Read-only limit is not working and expected. Save the guest
2. Create rhel6 HVM guest2  with SCSI read-only on xen-115 build without the fix. Read-only limit is not working and expected. Save the guest

Then, update kernel-xen to latest and xen to 116 build with the fix.

3. Restore guest1 from saved state,  Read-only limit is not working and expected.
Then start the guest again and failed with expected error message saying "IDE read-only not supported"

4. Restore guest2 from saved state,  try to write on the read-only disk but FAILED  and there is some error log in guest's /var/log/messages. 
attachment(attachment 449921 [details])

5. Create guest2 with SCSI read-only again, this time there is no error message in guest and saying the disk is read-only protected.(attachment 449922 [details])

Now, I am wonder if it is OK with the error message in step 4?

In the SCSI case, the journal will look as if there was a power failure after the restore, but otherwise it will work.  So the aborted transactions are okay.

The warning in fs/buffers.c is a separate bug in RHEL6.  I think it's harmless, since whatever happens won't be reflected on the disk (which is read only) but it should be reported.

Thanks!

OK, then I think I can mark this bug verified based on comment 25.
Did same test on xen i386 build with 32bit guest, read only patch is also working fine.

For the error message in attachment 449921 [details] , there is similar bugs reported:
rhbz614206, rhbz591466

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,3 +1 @@
-For fully-virtualized Xen guests, Previous versions of RHEL allowed the creation of read-only emulated disks (IDE or SCSI), but ignored the read-only attribute and let the guest write to the disk.  Starting with RHEL 5.6, SCSI disks will properly report the read-only bit, while read-only IDE disks are not allowed---in the presence of such a configuration, the guest will refuse to start.
+For fully-virtualized Xen guests, previous versions of Red Hat Enterprise Linux allowed the creation of read-only emulated disks (IDE or SCSI), but ignored the read-only attribute and let the guest write to the disk. Starting with Red Hat Enterprise Linux 5.6, SCSI disks properly report the read-only information, while read-only IDE disks are not allowed (in case of such a configuration, the guest will refuse to start). Migrations and restores of guests started under older versions of Xen have a different behavior to avoid backward incompatibility. SCSI disks will start reporting write errors after successful restore or migration, while for IDE disks the old (incorrect) behaviour will be preserved.-
-Migrations and restores of guests started under older version of Xen have a different behavior to avoid backward incompatibility.  SCSI disks will start reporting write errors after successful restore or migration, while for IDE disks the old (incorrect) behaviour will be preserved.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0031.html