Red Hat Bugzilla – Bug 1051350
Support the readonly attribute for SCSI passthrough devices
Last modified: 2016-11-03 14:07:36 EDT
Description of problem: After passthrough the SCSI device to the guest with readonly attribute, the devices in guest still can be wrote. From the result of step 4, you can see libvirt has finished this feature, should be one qemu issue. There is one qemu bug 995415, but this qemu bug is moved to rhel7.1. So we new this libvirt to track this issue in rhel7.1. And add "TestOnly" keyword. Version-Release number of selected component (if applicable): libvirt-1.1.1-17.el7.x86_64 qemu-kvm-rhev-1.5.3-30.el7.x86_64 kernel-3.10.0-65.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. add the following xml to the guest: <hostdev mode='subsystem' type='scsi' managed='no'> <source> <adapter name='scsi_host0'/> <address bus='0' target='0' unit='0'/> </source> <readonly/> <alias name='hostdev0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </hostdev> 2. start the guest # virsh start a Domain a started 3. login the guest In guest: 3.1 make sure the SCSI deivce is in the guest: # fdisk -l ...... Disk /dev/sdb: 500.1 GB, 500107862016 bytes 139 heads, 49 sectors/track, 143411 cylinders Units = cylinders of 6811 * 512 = 3487232 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x29781cf9 Device Boot Start End Blocks Id System /dev/sdb1 1 3080 10485760 83 Linux ...... 3.2 touch one file in the passthrough SCSI device------------------------the result is not as expected, it should be readonly, can't be wrote. # mount /dev/sdb1 /mnt/ # ls /mnt/ lost+found # touch /mnt/new # ls /mnt/ lost+found new 4. check the qemu command, libvirt pass the readonly successfully to qemu command. ...... -drive file=/dev/sg0,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 ...... Actual results: As step 3.2 Expected results: Should not write to the passthrough SCSI device in step 3.2 Additional info:
Bug 995415 for qemu-kvm-rhev is moved to RHEL7.2.
set bz 995415 to needinfo and ask if any updates happened in that bg. And this testonly bg shows the readonly works but with small problem. 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.
Verified on: libvirt-1.3.5-1.el7.x86_64 qemu-kvm-rhev-2.6.0-5.el7.x86_64 On HOST: # lsscsi [0:0:0:0] disk ATA WDC WD5000AAKX-6 1H18 /dev/sda [2:0:0:0] cd/dvd hp CDDVDW SH-216BB HE50 /dev/sr0 [6:0:0:0] storage IET Controller 0001 - [6:0:0:1] disk IET VIRTUAL-DISK 0001 /dev/sdb [6:0:0:2] disk IET VIRTUAL-DISK 0001 /dev/sdc [6:0:0:3] disk IET VIRTUAL-DISK 0001 /dev/sdd # mkfs.ext4 /dev/sdb mke2fs 1.42.9 (28-Dec-2013) /dev/sdb is entire device, not just one partition! Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 65536 inodes, 262144 blocks 13107 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=268435456 8 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done # virsh list Id Name State ---------------------------------------------------- 8 virtlab_test running # virsh dumpxml virtlab_test | grep hostdev -A10 <hostdev mode='subsystem' type='scsi' managed='no'> <source> <adapter name='scsi_host6'/> <address bus='0' target='0' unit='1'/> </source> <readonly/> <alias name='hostdev0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </hostdev> ... On GUEST: # mkfs.ext4 /dev/sda mke2fs 1.42.12 (29-Aug-2014) /dev/sda contains a ext4 file system created on Tue Jun 14 02:47:19 2016 Proceed anyway? (y,n) y /dev/sda: Read-only file system while setting up superblock # mount /dev/sda /mnt/ mount: /dev/sda is write-protected, mounting read-only # echo "hahha" > /mnt/1.txt -bash: /mnt/1.txt: Read-only file system # ll /mnt total 16 drwx------ 2 root root 16384 Jun 14 02:47 lost+found
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/RHSA-2016-2577.html