Created attachment 784774 [details]
dmesg info in guest

Libvirt will not trigger this and direct usage of qemu is not going to be supported in RHEL7.

(In reply to Ademar de Souza Reis Jr. from comment #3)
> Libvirt will not trigger this and direct usage of qemu is not going to be
> supported in RHEL7.
No, please refer to bug 957292#c8 and bug 957292#c9, reopen this bug for fixing. Please correct me if any mistake, thanks.

Best Regards,
sluo

With SCSI passthrough devices, the qemu block layer isn't involved in interpreting
the commands. The best thing we could do, is to outright fail the start of VM that
uses a read-only backend. However, this might make it impossible to actually make
use of real read-only backends.

You are using passthrough, so QEMU is not reporting the disk as write protected.  But the writes then fail according to the dmesg in comment 0 (this seems to be a difference between this bug and the RHEL6 bug 993537).

We could "patch" the MODE SENSE result and set the write protect bit (which is in a different place for disks and tapes), but in the meanwhile this is expected behavior.

Moving to 7.1.0 for now.

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

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

oVirt is working around this (bug 1082673), moving.

I tried steps in bz 1051350. Seems the readonly partially works, but with a tiny problem. Just wonder if the current bz 995415 has any update?

My env
Host Versions:
libvirt-1.2.17-7.el7.x86_64
qemu-kvm-rhev-2.3.0-22.el7.x86_64
kernel-3.10.0-304.el7.x86_64

Guest OS versions:
kernel-3.10.0-313.el7.x86_64

Steps:
Prepare a iscsi lun 
# lsscsi
...      
[15:0:0:1]   disk    IET      VIRTUAL-DISK     0001  /dev/sdi 


In Host:
1. add following xml seg in to vm's xml
# virsh edit rhel7_Sep4
...
    <hostdev mode='subsystem' type='scsi' managed='no'>
      <source>
        <adapter name='scsi_host15'/>
        <address bus='0' target='0' unit='1'/>
      </source>
      <readonly/>
    </hostdev>
2. start the guest
#virsh start rhel7_Sep4

3. check the qemu cmd
#ps -ef | grep qemu-kvm
/usr/libexec/qemu-kvm -name rhel7_Sep4 -S -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off,vmport=off -cpu SandyBridge -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid d6caff70-2e88-4973-816c-997290ea1b1a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-rhel7_Sep4/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x9 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/pool/rhel7_Sep4.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:64:b8:97,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-rhel7_Sep4/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5901,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -drive file=/dev/sg11,if=none,id=drive-hostdev0,readonly=on -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-hostdev0,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on

In Guest:
(sda is already mkfs.ext4'd previously)
1. # mount /dev/sda /mnt
2. ll /mnt    <==== there are some existing files. 
total 20
-rw-r--r--. 1 root root     5 Sep  7 14:20 1
-rw-r--r--. 1 root root     0 Sep  7 14:18 21
drwx------. 2 root root 16384 Sep  7 14:17 lost+found

3. write to sda <=== sda seems still can be written
[root@localhost ~]# echo "test" > /mnt/3
[root@localhost ~]# cat /mnt/3 
test

4. in a few seconds, there are following errors produced in /var/log/messages
#tailf /var/log/messages
...
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] Sense Key : Aborted Command [current] 
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] Add. Sense: I/O process terminated
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] CDB: Write(10) 2a 00 00 10 00 00 00 00 08 00
Sep  7 15:33:24 localhost kernel: blk_update_request: I/O error, dev sda, sector 1048576
Sep  7 15:33:24 localhost kernel: Buffer I/O error on device sda, logical block 131072
Sep  7 15:33:24 localhost kernel: lost page write due to I/O error on sda
Sep  7 15:33:24 localhost kernel: JBD2: Error -5 detected when updating journal superblock for sda-8.
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] Sense Key : Aborted Command [current] 
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] Add. Sense: I/O process terminated
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] CDB: Write(10) 2a 00 00 10 00 08 00 00 30 00
Sep  7 15:33:24 localhost kernel: blk_update_request: I/O error, dev sda, sector 1048584
Sep  7 15:33:24 localhost kernel: Aborting journal on device sda-8.
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] Sense Key : Aborted Command [current] 
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] Add. Sense: I/O process terminated
Sep  7 15:33:24 localhost kernel: sd 2:0:0:0: [sda] CDB: Write(10) 2a 00 00 10 00 00 00 00 08 00
Sep  7 15:33:24 localhost kernel: blk_update_request: I/O error, dev sda, sector 1048576
Sep  7 15:33:24 localhost kernel: Buffer I/O error on device sda, logical block 131072
Sep  7 15:33:24 localhost kernel: lost page write due to I/O error on sda
Sep  7 15:33:24 localhost kernel: JBD2: Error -5 detected when updating journal superblock for sda-8.

5. after errors logged in /var/log/messages, the sda cannot be written anymore with explicit error in terminal, as follow:

# echo "test" > /mnt/4
-bash: /mnt/4: Read-only file system



In guest step 3, the write option should be failed and error should be popped up to terminal. And actually, if I remount the /dev/sda, the data generated in step 3 is lost.

Fixed by commit 0eb2baeb449d27d6e6208a257dba6be1aad4d476.

Mirek, can you add it to the errata?

Reproduce:
qemu-kvm-rhev-2.3.0-31.el7
kernel-3.10.0-497.el7.x86_64

Steps:
1. Boot guest with passthrough scsi-disk (/dev/sdb, readonly=on)
# /usr/libexec/qemu-kvm -name rhel73 -m 8G,slots=240,maxmem=200G -smp 16 \

 -no-user-config -nodefaults  \

-drive file=/home/guest/rhel73.qcow2,if=none,id=drive-disk,format=qcow2,cache=none -device virtio-scsi-pci,id=scsi0 -device scsi-hd,drive=drive-disk,id=hd0  \

-usb -device usb-tablet,id=input0 -netdev tap,id=hostnet1 -device virtio-net-pci,mac=42:ce:a9:d2:4d:d9,id=idlbq7eA,netdev=hostnet1 -vga qxl -spice port=5901,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on -monitor stdio  \ 

-drive file=/dev/sdb,if=none,id=drive-data-disk,format=raw,werror=stop,rerror=stop,readonly=on -device scsi-block,drive=drive-data-disk,id=data-disk

2. Format the disk in guest
# mkfs.xfs -f /dev/sdb
meta-data=/dev/sdb               isize=512    agcount=4, agsize=3276800 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=13107200, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=6400, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

# mount /dev/sdb  /mnt/
# touch /mnt/test.txt 
# ls /mnt/
test.txt

The format operation succeed and the disk is writable.
So the bug is reproduced.

Verify:
qemu-kvm-rhev-2.6.0-23.el7
kernel-3.10.0-497.el7.x86_64

With same steps as above, format operation fails and error message is prompted:
# mkfs.xfs -f /dev/sdb
mkfs.xfs: cannot open /dev/sdb: Read-only file system

So the bug is fixed.

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://rhn.redhat.com/errata/RHBA-2016-2673.html