This setup should definitely work; I had tested it (= scsi-block / LUN passthrough) months (years?) ago, also with a USB stick.

(1) Please collect the OVMF debug log (by adding the following options to the QEMU command line), and then attach it to the bugzilla.

  -debugcon file:/tmp/scsi_test2_Q35.ovmf.log \
  -global isa-debugcon.iobase=0x402

(Providing the OVMF debug log should be a standard part of OVMF BZs.)

(2) Please provide as much information about the USB stick as possible.

I expect that the USB driver stack in edk2 -- that OVMF includes unmodified -- has trouble dealing with the particular USB stick that you are using.

(3) Another thing to try: please drop the second virtio-scsi HBA (called "scsi_pci_bus1"), and place the drive named "drive_usb" on the first HBA (called "scsi_pci_bus0").

Thanks.

(In reply to Laszlo Ersek from comment #1)
> This setup should definitely work; I had tested it (= scsi-block / LUN
> passthrough) months (years?) ago, also with a USB stick.
> 
> (1) Please collect the OVMF debug log (by adding the following options to
> the QEMU command line), and then attach it to the bugzilla.
> 
>   -debugcon file:/tmp/scsi_test2_Q35.ovmf.log \
>   -global isa-debugcon.iobase=0x402
> 
> (Providing the OVMF debug log should be a standard part of OVMF BZs.)
> 

  Attachment "scsi_test2_Q35_1.ovmf.log" is OVMF debug log with original QEMU command line.

> (2) Please provide as much information about the USB stick as possible.
> 
> I expect that the USB driver stack in edk2 -- that OVMF includes unmodified
> -- has trouble dealing with the particular USB stick that you are using.

1) USB 3.0
2) In host:
# lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 002 Device 003: ID 0557:7000 ATEN International Co., Ltd Hub
Bus 002 Device 012: ID 1516:6221 **CompUSA**
Bus 002 Device 004: ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch
3) (qemu) info usbhost
  Bus 2, Addr 11, Port 1.8, Speed 480 Mb/s
    Class 00: USB device 1516:6221, 
  Bus 2, Addr 4, Port 1.6.1, Speed 1.5 Mb/s
    Class 00: USB device 0557:2213, CS-1734A V4.1.401

Created attachment 1152146 [details]
OVMF debug log with original QEMU command line

(In reply to Laszlo Ersek from comment #2)
> (3) Another thing to try: please drop the second virtio-scsi HBA (called
> "scsi_pci_bus1"), and place the drive named "drive_usb" on the first HBA
> (called "scsi_pci_bus0").
> 
> Thanks.

1)Start a VM using following commands:
 ...
 -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
 -drive file=/home/scsi_test2_Q35/rhev7.3_VARS.fd,if=pflash,format=raw,unit=1 \
 ...
 -device virtio-scsi-pci,id=scsi_pci_bus0 \
 -drive file=/dev/sdb,format=qcow2,id=drive_sysdisk,if=none,cache=none,aio=native,werror=stop,rerror=stop \
 -device scsi-hd,drive=drive_sysdisk,bus=scsi_pci_bus0.0,id=device_sysdisk,bootindex=0 \
 -drive file=/dev/sdi,format=raw,if=none,id=drive_usb,aio=native \
 -device scsi-block,bus=scsi_pci_bus0.0,drive=drive_usb,id=device_usb \
 ...

2)The result is not changed.
3)Attachment "scsi_test2_Q35_2.ovmf.log" is OVMF debug log with new QEMU command line.

Created attachment 1152153 [details]
OVMF debug log with new QEMU command line

Created attachment 1152203 [details]
OVMF debug log

Okay, I googled the device 1516:6221. It looks like a USB (3.0) stick -- funnily enough, I found a whole bunch of RHBZs reported by QE, using this stick. Apparently it is a standard testing tool in virt QE :)

I'm pretty sure something in the SCSI command stream goes wrong, when passing through the scsi disk interface of this device. Can you please give me access to the host where this stick is plugged in? (Please respond with a private comment, of course.)

All I can see / suspect from the OVMF logs is that the firmware hangs when it is issuing SCSI commands.

Okay, I found the problem. The USB stick is broken, it violates the SPC-4 specification. And, that causes the SCSI disk driver in edk2 to fall into an infinite loop.

Proof for the USB stick being broken:

# sg_vpd -v /dev/sdi
Supported VPD pages VPD page:
    inquiry cdb: 12 01 00 00 fc 00 
invalid VPD response; probably a STANDARD INQUIRY response
First 32 bytes of bad response
 00     00 80 06 02 1f 00 00 00  00 00 00 00 00 00 00 00    ................
 10     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ................
fetching VPD page failed

Compare with /dev/sda:

# sg_vpd -v /dev/sda
Supported VPD pages VPD page:
    inquiry cdb: 12 01 00 00 fc 00 
   [PQual=0  Peripheral device type: disk]
  Supported VPD pages [sv]
  Unit serial number [sn]
  Device identification [di]
  ATA information (SAT) [ai]
  Block limits (SBC) [bl]
  Block device characteristics (SBC) [bdc]
  Logical block provisioning (SBC) [lbpv]

I have a patch for edk2 that catches this device error and works it around. I can boot OVMF with it on the host provided by QE, using the USB stick as scsi-block passthrough. (I didn't try to boot an actual OS.)

For more background, refer to kernel commit 09b6b51b0b6c. That commit (which is part of RHEL-7.0) is the reason why the host kernel doesn't choke on the device. In a nutshell, the SCSI disk driver in the kernel assumes that *all* USB storage devices are broken with regard to all VPD pages, plain and simple.

Posted upstream patch:
http://thread.gmane.org/gmane.comp.bios.edk2.devel/11623

Actually, now I wonder if this is a bug in the host kernel's usb-storage
driver.

(1) As far as I understand, the CDB from the guest is forwarded unmodified
    to the host USB device:

    - The guest composes the INQUIRY command, with the EVPD bit set.
    - QEMU forwards it with SG_IO to the host kernel.
    - In the host kernel, the block layer / SCSI disk driver forwards it to
      the usb-storage driver.
    - The usb-storage driver forwards it to the USB flash drive.
    - The usb-storage driver receives a CDB where the EVPD is set for the
      INQUIRY command -- which is invalid.

(2) The SPC-4 spec says in "6.4 INQUIRY command":

> An enable vital product data ( EVPD ) bit set to one specifies that the
> device server shall return the vital product data specified by the PAGE
> CODE field (see 7.8). If the device server does not implement the
> requested vital product data page, then the command shall be terminated
> with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST,
> and the additional sense code set to INVALID FIELD IN CDB.
>
> An EVPD bit is set to zero specified that the device server shall return
> the standard INQUIRY data (see 6.4.2). [...]

(3) The usb-storage driver turns this SCSI command into a UFI ("USB Floppy
    Interface") command *transparently*. The following document:

      Universal Serial Bus
      Mass Storage Class

      Specification Overview

    says in section "2 Subclass Codes":

> The Interface Descriptor of a USB Mass Storage Class device includes a
> /bInterfaceSubClass/ field. This field denotes the industry-standard
> command set transported by a Mass Storage Class interface. The value of
> the /bInterfaceSubClass/ field shall be set to one of the Subclass codes
> as shown in table 1.
>
> The Subclass code values used in the /bInterfaceSubClass/ field specify
> the industry-standard specification that defines transport command sets
> transported by the interface; [...]
>
> [...]
>
> Subclass:                    06h
> Command Block Specification: SCSI transparent command set
> Comment:                     Allocated by USB-IF for SCSI. SCSI standards
>                              are defined

    And, "lsusb -v" reports the following for the device:

> Bus 002 Device 005: ID 1516:6221 CompUSA
> Device Descriptor:
>   idVendor           0x1516 CompUSA
>   idProduct          0x6221
>   Configuration Descriptor:
>     bNumInterfaces          1
>     Interface Descriptor:
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI           <-------- right here

    Okay, so we know the CDB will be forwarded transparently. How will the
    device interpret the CDB?

(4) The document

      Universal Serial Bus
      Mass Storage Class

      UFI Command
      Specification

    says in "1.1 Scope":

> The "USB Floppy Interface" (UFI) Command Set is based on the SCSI-2 and
> SFF-8070i command sets.

    In "3. UFI Commands":

> The format of each command block is based on SFF-8070i and SCSI-2.

    In "4.2 INQUIRY Command: 12h":

> The EVPD (Enable Vital Product Data) is set to zero.

    So, what we have here is the following: the guest firmware composes an
    INQUIRY command with the EVPD bit set. QEMU and the host kernel forward
    this CDB unmodified to the USB flash drive (which has interface subclass
    0x06 -- SCSI), in the form of an INQUIRY UFI command.

    However, the specification for the INQUIRY UFI command requires that the
    EVPD bit be clear! The device is actually allowed to *assume* (without
    looking) that the EVPD bit will be clear, because the UFI command spec
    requires the submitter of the command to clear the EVPD bit!

    This is why the device simply returns a standard INQUIRY response (not
    Vital Product Data pages) for the command. The device is actually
    working fine.

(5) So, the question becomes, what layer is at fault, what layer should be
    fixed.

    The host kernel currently tries to solve this problem through commit
    09b6b51b0b6c. The USB storage driver sets "skip_vpd_pages" to 1, and
    then the SCSI disk driver will know not to set the EVPD in INQUIRY
    commands -- see the sd_try_extended_inquiry() function.

    The patch that I submitted for edk2 (see comment 16) sort of follows the
    same idea: it pushes the responsibility of not setting EVPD to the guest
    firmware (the end-composer of the SCSI CDB).

    I think this is wrong. Both host kernel commit 09b6b51b0b6c and my edk2
    patch are misguided. The USB storage driver in the host kernel exposes a
    standard SCSI interface. Submitting INQUIRY commands against that, with
    the EVPD bit set, is perfectly valid.

    The mapping to UFI commands is an internal matter of the USB storage
    driver. The fact that EVPD must be clear for UFI commands should be
    hidden from the consumer of the standard SCSI interface; be it the SCSI
    disk driver in the host kernel, the "sg_vpd" command line utility on the
    host, the QEMU process issuing SG_IO ioctl()s on the host, or a SCSI
    disk driver in the guest.

    The SPC-4 specification actually describes how the USB storage driver
    should handle the case when the EVPD bit is set. First, the USB storage
    driver should *notice* if the EVPD bit is set in the INQUIRY. Second, it
    should automatically reject the INQUIRY without accessing the device, by
    synthetizing a CHECK CONDITION status, with ILLEGAL REQUEST sense, and
    an INVALID FIELD IN CDB asc.

    In practical terms, the "sg_vpd" test (in comment 14) should not report
    "invalid VPD response; probably a STANDARD INQUIRY response"; it should
    print a CHECK CONDITION, synthetized by the usb-storage driver in the
    kernel.

I'm CC'ing Paolo and Gerd for SCSI and USB expertise. I'm also moving the
bug to the (host) kernel component, at least for triage / discussion (I'm
changing the title accordingly).

Aaaargh, I'm wrong. Namely:

(In reply to Laszlo Ersek from comment #17)

> (3) The usb-storage driver turns this SCSI command into a UFI ("USB Floppy
>     Interface") command *transparently*. The following document:
> 
>       Universal Serial Bus
>       Mass Storage Class
> 
>       Specification Overview
> 
>     says in section "2 Subclass Codes":
> 
> > The Interface Descriptor of a USB Mass Storage Class device includes a
> > /bInterfaceSubClass/ field. This field denotes the industry-standard
> > command set transported by a Mass Storage Class interface. The value of
> > the /bInterfaceSubClass/ field shall be set to one of the Subclass codes
> > as shown in table 1.
> >
> > The Subclass code values used in the /bInterfaceSubClass/ field specify
> > the industry-standard specification that defines transport command sets
> > transported by the interface; [...]
> >
> > [...]
> >
> > Subclass:                    06h
> > Command Block Specification: SCSI transparent command set
> > Comment:                     Allocated by USB-IF for SCSI. SCSI
> >                              standards are defined outside of USB.
> >

My statement

    The usb-storage driver turns this SCSI command into a UFI ("USB Floppy
    Interface") command *transparently*

is completely bogus.

I missed that in the exact same table, the UFI command set belongs to a
separate subclass, namely:

  Subclass:                    04h
  Command Block Specification: UFI
  Comment:                     Specifies how to interface Floppy Disk Drives
                               to USB

So, given that the subclass of the device in question is 06h ("SCSI
transparent command set"), it *really* should handle the INQUIRY+EVPD CDB.
Meaning that the USB storage driver in Linux is correct, and the device is
broken.

Upstream commit ce1647fc608e.

Reproduced with qemu-kvm-rhev-2.5.0-4.el7.x86_64.rpm and OVMF-20160419-2.git90bb4c5.el7.noarch.rpm.

Verified it with OVMF-20160419-2.git90bb4c5.el7.noarch.rpm and qemu-kvm-rhev-2.6.0-19.el7.x86_64

1. Boot guest with following cli:
/usr/libexec/qemu-kvm \
 -S \
 -name 'rhel7.3-64' \
 -machine q35,accel=kvm,usb=off,vmport=off \
 -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
 -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
 -m 4096 \
 -smp 4,maxcpus=4,cores=2,threads=2,sockets=1 \
 -cpu Nehalem \
 -rtc base=localtime,clock=host,driftfix=slew \
 -nodefaults \
 -vga qxl \
 -netdev tap,id=netdev0,vhost=on \
 -device virtio-net-pci,mac=BA:BC:13:83:4F:BD,id=net0,netdev=netdev0,status=on,bus=pcie.0 \
 -device ioh3420,bus=pcie.0,id=root.0,slot=1 \
 -device x3130-upstream,bus=root.0,id=upstream1 \
 -device xio3130-downstream,bus=upstream1,id=downstream1,chassis=1 \
 -device xio3130-downstream,bus=upstream1,id=downstream2,chassis=2 \
 -device xio3130-downstream,bus=upstream1,id=downstream3,chassis=3 \
 -device xio3130-downstream,bus=upstream1,id=downstream4,chassis=4 \
 -device xio3130-downstream,bus=upstream1,id=downstream5,chassis=5 \
 -device xio3130-downstream,bus=upstream1,id=downstream6,chassis=6 \
 -device virtio-scsi-pci,bus=downstream1,id=scsi_pci_bus0 \
 -drive file=/home/pxb-ovmf.qcow2,format=qcow2,id=drive_sysdisk,if=none,cache=none,aio=native,werror=stop,rerror=stop \
 -device scsi-hd,drive=drive_sysdisk,bus=scsi_pci_bus0.0,id=device_sysdisk,bootindex=0,physical_block_size=512,logical_block_size=512,serial=12345678900987654321,ver=SYSDISK,wwn=0x123,channel=0,scsi-id=0,lun=0 \
 -device virtio-scsi-pci,bus=downstream2,id=scsi_pci_bus1 \
 -device virtio-scsi-pci,bus=downstream3,id=scsi_pci_bus2 \
 -device virtio-scsi-pci,bus=downstream4,id=scsi_pci_bus3 \
 -boot menu=on \
 -enable-kvm \
 -monitor stdio \
 -spice port=5900,disable-ticketing \
 -qmp tcp:0:6666,server,nowait

2. rhel7.3 guest can boot up successfully

(In reply to jingzhao from comment #23)
> Reproduced with qemu-kvm-rhev-2.5.0-4.el7.x86_64.rpm and
> OVMF-20160419-2.git90bb4c5.el7.noarch.rpm.
> 
> Verified it with OVMF-20160419-2.git90bb4c5.el7.noarch.rpm and
> qemu-kvm-rhev-2.6.0-19.el7.x86_64

Correct the command line:
/usr/libexec/qemu-kvm \
-M q35 \
-cpu SandyBridge \
-nodefaults -rtc base=utc \
-m 4G \
-smp 2,sockets=2,cores=1,threads=1 \
-enable-kvm \
-name rhel7.3 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-serial unix:/tmp/console,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-chardev file,path=/home/e1000e/seabios.log,id=seabios \
-device isa-debugcon,chardev=seabios,iobase=0x402 \
-qmp tcp::8887,server,nowait \
-vga qxl \
-spice port=5932,disable-ticketing \
-device ioh3420,id=root.0,slot=1 \
-drive file=/home/e1000e/72.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,bus=root.0,drive=drive-virtio-disk0,id=virtio-disk0,disable-legacy=on,disable-modern=off,bootindex=1 \
-device ioh3420,id=root.1,slot=2 \
-device x3130-upstream,bus=root.1,id=upstream1 \
-device xio3130-downstream,bus=upstream1,id=downstream1,chassis=1 \
-device xio3130-downstream,bus=upstream1,id=downstream2,chassis=2 \
-device xio3130-downstream,bus=upstream1,id=downstream3,chassis=3 \
-drive file=/home/e1000e/block1.qcow2,if=none,id=drive-virtio-disk1,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,bus=downstream1,drive=drive-virtio-disk1,id=virtio-disk1,disable-legacy=on,disable-modern=off \
-device virtio-scsi-pci,id=scsi0,bus=downstream2,disable-legacy=on,disable-modern=off \
-drive file=/home/e1000e/block2.raw,if=none,id=drive-virtio-disk2,format=raw,cache=none,werror=stop,rerror=stop \
-device scsi-hd,bus=scsi0.0,drive=drive-virtio-disk2,id=virtio-disk2 \
-device ioh3420,id=root.2,slot=3 \
-netdev tap,id=hostnet1 \
-device e1000e,netdev=hostnet1,id=net1,mac=54:52:00:B6:40:22,bus=root.2 \
-monitor stdio \
[root@localhost e1000e]# vim install.sh 
[root@localhost e1000e]# cd /home/
[root@localhost home]# cat bug1333238 
/usr/libexec/qemu-kvm \
 -S \
 -name 'rhel7.3-64' \
 -machine q35,accel=kvm,usb=off,vmport=off \
 -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
 -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
 -m 4096 \
 -smp 4,maxcpus=4,cores=2,threads=2,sockets=1 \
 -cpu Nehalem \
 -rtc base=localtime,clock=host,driftfix=slew \
 -nodefaults \
 -vga qxl \
 -netdev tap,id=netdev0,vhost=on \
 -device virtio-net-pci,mac=BA:BC:13:83:4F:BD,id=net0,netdev=netdev0,status=on,bus=pcie.0 \
 -device ioh3420,bus=pcie.0,id=root.0,slot=1 \
 -device x3130-upstream,bus=root.0,id=upstream1 \
 -device xio3130-downstream,bus=upstream1,id=downstream1,chassis=1 \
 -device xio3130-downstream,bus=upstream1,id=downstream2,chassis=2 \
 -device xio3130-downstream,bus=upstream1,id=downstream3,chassis=3 \
 -device xio3130-downstream,bus=upstream1,id=downstream4,chassis=4 \
 -device xio3130-downstream,bus=upstream1,id=downstream5,chassis=5 \
 -device xio3130-downstream,bus=upstream1,id=downstream6,chassis=6 \
 -device virtio-scsi-pci,bus=downstream1,id=scsi_pci_bus0 \
 -drive file=/home/pxb-ovmf.qcow2,format=qcow2,id=drive_sysdisk,if=none,cache=none,aio=native,werror=stop,rerror=stop \
 -device scsi-hd,drive=drive_sysdisk,bus=scsi_pci_bus0.0,id=device_sysdisk,bootindex=0,physical_block_size=512,logical_block_size=512,serial=12345678900987654321,ver=SYSDISK,wwn=0x123,channel=0,scsi-id=0,lun=0 \
 -device virtio-scsi-pci,id=scsi_pci_bus1 \
 -drive file=/dev/sdb,format=raw,if=none,id=drive_usb,aio=native,cache.direct=on \
 -device scsi-block,bus=scsi_pci_bus1.0,drive=drive_usb,id=device_usb \
 -boot menu=on \
 -enable-kvm \
 -monitor stdio \
 -spice port=5900,disable-ticketing \
 -qmp tcp:0:6666,server,nowait


> 
> 1. Boot guest with following cli:
> /usr/libexec/qemu-kvm \
>  -S \
>  -name 'rhel7.3-64' \
>  -machine q35,accel=kvm,usb=off,vmport=off \
>  -drive
> file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,
> readonly=on \
>  -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
>  -m 4096 \
>  -smp 4,maxcpus=4,cores=2,threads=2,sockets=1 \
>  -cpu Nehalem \
>  -rtc base=localtime,clock=host,driftfix=slew \
>  -nodefaults \
>  -vga qxl \
>  -netdev tap,id=netdev0,vhost=on \
>  -device
> virtio-net-pci,mac=BA:BC:13:83:4F:BD,id=net0,netdev=netdev0,status=on,
> bus=pcie.0 \
>  -device ioh3420,bus=pcie.0,id=root.0,slot=1 \
>  -device x3130-upstream,bus=root.0,id=upstream1 \
>  -device xio3130-downstream,bus=upstream1,id=downstream1,chassis=1 \
>  -device xio3130-downstream,bus=upstream1,id=downstream2,chassis=2 \
>  -device xio3130-downstream,bus=upstream1,id=downstream3,chassis=3 \
>  -device xio3130-downstream,bus=upstream1,id=downstream4,chassis=4 \
>  -device xio3130-downstream,bus=upstream1,id=downstream5,chassis=5 \
>  -device xio3130-downstream,bus=upstream1,id=downstream6,chassis=6 \
>  -device virtio-scsi-pci,bus=downstream1,id=scsi_pci_bus0 \
>  -drive
> file=/home/pxb-ovmf.qcow2,format=qcow2,id=drive_sysdisk,if=none,cache=none,
> aio=native,werror=stop,rerror=stop \
>  -device
> scsi-hd,drive=drive_sysdisk,bus=scsi_pci_bus0.0,id=device_sysdisk,
> bootindex=0,physical_block_size=512,logical_block_size=512,
> serial=12345678900987654321,ver=SYSDISK,wwn=0x123,channel=0,scsi-id=0,lun=0 \
>  -device virtio-scsi-pci,bus=downstream2,id=scsi_pci_bus1 \
>  -device virtio-scsi-pci,bus=downstream3,id=scsi_pci_bus2 \
>  -device virtio-scsi-pci,bus=downstream4,id=scsi_pci_bus3 \
>  -boot menu=on \
>  -enable-kvm \
>  -monitor stdio \
>  -spice port=5900,disable-ticketing \
>  -qmp tcp:0:6666,server,nowait
> 
> 2. rhel7.3 guest can boot up successfully

2. guest can boot up successfully
3. disk can be found in guest
[root@localhost ~]# lsblk
NAME                            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                               8:0    1 14.7G  0 disk 
sdb                               8:16   0   30G  0 disk 
├─sdb1                            8:17   0  200M  0 part /boot/efi
├─sdb2                            8:18   0    1G  0 part /boot
└─sdb3                            8:19   0 28.8G  0 part 
  ├─rhel_dhcp--66--145--44-root 253:0    0 25.8G  0 lvm  /
  └─rhel_dhcp--66--145--44-swap 253:1    0    3G  0 lvm  [SWAP]

Has verified, it has been resolved.

Verified Version:
 Kernel version:3.10.0-504.el7.x86_64
 qemu-kvm-rhev version:qemu-kvm-rhev-2.6.0-22.el7.x86_64
 OVMF version:OVMF-20160608-3.git988715a.el7.noarch

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-2608.html