Bug 1330955
| Summary: | VM can not be booted up from hard disk successfully when with a passthrough USB stick | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | yduan | ||||||||||
| Component: | ovmf | Assignee: | Laszlo Ersek <lersek> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | aihua liang <aliang> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 7.3 | CC: | chayang, huding, jinzhao, juzhang, kraxel, lersek, mrezanin, pbonzini, qizhu, xfu, yduan | ||||||||||
| Target Milestone: | rc | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | ovmf-20160608-1.git988715a.el7 | Doc Type: | Bug Fix | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2016-11-04 08:40:22 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
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 |
Created attachment 1151296 [details] Boot up procedure hangs Description of problem: VM can not be booted up from hard disk successfully when with a passthrough USB stick. Version-Release number of selected component (if applicable): Host: kernel-3.10.0-382.el7.x86_64 qemu-kvm-rhev-2.5.0-4.el7.x86_64 OVMF-20160202-2.gitd7c0dfa.el7.noarch Guest: kernel-3.10.0-382.el7.x86_64 How reproducible: 100% Steps to Reproduce: 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 \ -device virtio-scsi-pci,id=scsi_pci_bus1 \ -drive file=/dev/sdi,format=raw,if=none,id=drive_usb,aio=native \ -device scsi-block,bus=scsi_pci_bus1.0,drive=drive_usb,id=device_usb \ ... Actual results: Boot up procedure hangs as attachment. Expected results: VM should be booted up from hard disk successfully. Additional info: 1.VM can be booted up from hard disk successfully without following commands: -drive file=/dev/sdi,format=raw,if=none,id=drive_usb,aio=native \ -device scsi-block,bus=scsi_pci_bus1.0,drive=drive_usb,id=device_usb \ 2.Not reproducible with seabios-1.9.1-2.el7.x86_64.