+++ This bug was initially created as a clone of Bug #1972091 +++ Description of problem: It's not possible to start installation from a virtual USB device on aarch64: # virt-install --os-variant rhel8-unknown --arch aarch64 --disk /var/lib/libvirt/images/boot.iso,bus=usb --boot uefi --name test --memory 2048 --disk size=10 --graphics none Starting install... Allocating 'test.qcow2' | 10 GB 00:00:00 ERROR unsupported configuration: This QEMU doesn't support '-device usb-storage' Version-Release number of selected component (if applicable): qemu-kvm-4.2.0-51.module+el8.5.0+11141+9dff516f.aarch64 virt-install-2.2.1-4.el8.noarch How reproducible: Always on aarch64 Steps to Reproduce: 1. virt-install --os-variant rhel8-unknown --arch aarch64 --disk /var/lib/libvirt/images/boot.iso,bus=usb --boot uefi --name test --memory 2048 --disk size=10 --graphics none Actual results: ERROR unsupported configuration: This QEMU doesn't support '-device usb-storage' Expected results: It's possible to start installation from a USB device --- Additional comment from Andrew Jones on 2021-06-15 17:29:41 CST --- We don't support running AArch64 VMs without the AV version of qemu-kvm. If this use case is expected to work because it's commonly used by other architectures and/or is documented in the Virt user's guide, then please test again with the AV qemu-kvm to see if works there. If not, please move this BZ to that product. That said, is this a regression? I.e. did this used to work with the non-AV version of qemu-kvm until recently? Hit this issue on rhel-av 8.5.0, qemu-kvm-6.0.0-20.module+el8.5.0+11499+199527ef So clone this bug to rhel-av 8.5.0. # /usr/libexec/qemu-kvm -cpu host -device help | grep usb name "usb-host", bus usb-bus name "usb-hub", bus usb-bus name "usb-kbd", bus usb-bus name "usb-mouse", bus usb-bus name "usb-tablet", bus usb-bus
Updated information Hit this issue on rhel 9.0.0, qemu-kvm-6.0.0-5.el9 too. So in which version do we plan to fix it? Do I need to report a new bug in rhel.9.0 to track it? # virt-install --os-variant rhel9-unknown --arch aarch64 --disk /home/kvm_autotest_root/iso/linux/RHEL9.0.0-BaseOS-aarch64.iso,bus=usb --boot uefi --name test --memory 2048 --disk size=10 --graphics none Starting install... Allocating 'test.qcow2' | 10 GB 00:00:00 Removing disk 'test.qcow2' | 0 B 00:00:00 ERROR unsupported configuration: This QEMU doesn't support '-device usb-storage' Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start test otherwise, please restart your installation. # /usr/libexec/qemu-kvm -cpu host -device help | grep usb name "usb-host", bus usb-bus name "usb-hub", bus usb-bus name "usb-kbd", bus usb-bus name "usb-mouse", bus usb-bus name "usb-tablet", bus usb-bus
Zhenyu, Can you answer Drew's questions from Bug 1972091 comment 1? Is this a regression? Does this work on x86? Thanks.
(In reply to Luiz Capitulino from comment #2) > Zhenyu, > > Can you answer Drew's questions from Bug 1972091 comment 1? Is this a > regression? Does this work on x86? Updated information: (In reply to Bug 1972091 Andrew Jones from comment #1) > We don't support running AArch64 VMs without the AV version of qemu-kvm. If > this use case is expected to work because it's commonly used by other > architectures and/or is documented in the Virt user's guide, then please > test again with the AV qemu-kvm to see if works there. If not, please move > this BZ to that product. > > That said, is this a regression? I.e. did this used to work with the non-AV > version of qemu-kvm until recently? Hello Drew, I tested the qemu-kvm-4.2.0-48.module+el8.4.0 and qemu-kvm-4.2.0-29.module+el8.2.1 versions, They also don't support "usb-storage". So I think this's not a regression. And I tested on x86,PowerPC, they work fine. on aarch64: qemu-kvm-4.2.0-48.module+el8.4.0+10368+630e803b /usr/libexec/qemu-kvm -cpu host -device help | grep usb name "usb-host", bus usb-bus name "usb-hub", bus usb-bus name "usb-kbd", bus usb-bus name "usb-mouse", bus usb-bus name "usb-tablet", bus usb-bus qemu-kvm-4.2.0-29.module+el8.2.1+11280+70ae3d73.8 /usr/libexec/qemu-kvm -cpu host -device help | grep usb name "usb-host", bus usb-bus name "usb-hub", bus usb-bus name "usb-kbd", bus usb-bus name "usb-mouse", bus usb-bus name "usb-tablet", bus usb-bus on x86_64: [root@dell-per730-47 ~]# /usr/libexec/qemu-kvm -version QEMU emulator version 5.2.0 (qemu-kvm-5.2.0-16.module+el8.4.0+11536+725e25d9.2) [root@dell-per730-47 ~]# /usr/libexec/qemu-kvm -cpu host -device help | grep usb name "usb-host", bus usb-bus name "usb-hub", bus usb-bus name "ich9-usb-ehci1", bus PCI name "ich9-usb-ehci2", bus PCI name "ich9-usb-uhci1", bus PCI name "ich9-usb-uhci2", bus PCI name "ich9-usb-uhci3", bus PCI name "ich9-usb-uhci4", bus PCI name "ich9-usb-uhci5", bus PCI name "ich9-usb-uhci6", bus PCI name "nec-usb-xhci", bus PCI name "piix3-usb-uhci", bus PCI name "piix4-usb-uhci", bus PCI name "usb-ehci", bus PCI name "vt82c686b-usb-uhci", bus PCI name "usb-bot", bus usb-bus name "usb-storage", bus usb-bus name "usb-ccid", bus usb-bus, desc "CCID Rev 1.1 smartcard reader" name "usb-kbd", bus usb-bus name "usb-mouse", bus usb-bus name "usb-tablet", bus usb-bus name "usb-redir", bus usb-bus on PowerPC: [root@ibm-p8-rhevm-12 ~]# /usr/libexec/qemu-kvm -version QEMU emulator version 5.2.0 (qemu-kvm-5.2.0-16.module+el8.4.0+11536+725e25d9.2) # /usr/libexec/qemu-kvm -cpu host -device help | grep usb name "usb-host", bus usb-bus name "usb-hub", bus usb-bus name "nec-usb-xhci", bus PCI name "usb-bot", bus usb-bus name "usb-storage", bus usb-bus name "usb-ccid", bus usb-bus, desc "CCID Rev 1.1 smartcard reader" name "usb-kbd", bus usb-bus name "usb-mouse", bus usb-bus name "usb-tablet", bus usb-bus
I think we'll just go ahead and add usb-storage in order to match the other architectures, but I'm curious as to why the other architectures support this? Does anybody know why?
(In reply to Andrew Jones from comment #4) > I think we'll just go ahead and add usb-storage in order to match the other > architectures, but I'm curious as to why the other architectures support > this? Does anybody know why? Hello XueQiang, Since you have been the owner of the x86 block function for a long time, could you answer this question? I'm not sure it's whether there are customers using such scenarios. Thanks Zhenyu
(In reply to Zhenyu Zhang from comment #5) > (In reply to Andrew Jones from comment #4) > > I think we'll just go ahead and add usb-storage in order to match the other > > architectures, but I'm curious as to why the other architectures support > > this? Does anybody know why? > > Hello XueQiang, > > Since you have been the owner of the x86 block function for a long time, > could you answer this question? > I'm not sure it's whether there are customers using such scenarios. > > Thanks > > Zhenyu Hi Yanbin, Could you help answer the question? I'm not sure if there is any update for usb-storage. Many thanks.
(In reply to Andrew Jones from comment #4) > I think we'll just go ahead and add usb-storage in order to match the other > architectures, but I'm curious as to why the other architectures support > this? Does anybody know why? "usb-storage" device is the emulation of the usb stick in qemu. Please check: https://github.com/qemu/qemu/blob/master/docs/usb-storage.txt
(In reply to yduan from comment #7) > > "usb-storage" device is the emulation of the usb stick in qemu. > I know what it is. I want to know why we want to support it for enterprise use cases in RHEL, which means maintaining it and testing it. Is it actually used by customers? Or are we doing all this work just because it's there...
(In reply to Andrew Jones from comment #8) > (In reply to yduan from comment #7) > > > > "usb-storage" device is the emulation of the usb stick in qemu. > > > > I know what it is. I want to know why we want to support it for enterprise > use cases in RHEL, which means maintaining it and testing it. Is it actually > used by customers? Or are we doing all this work just because it's there... Hello Martin, could you help share some insights from PM perspective for this question? Thanks a lot. Zhenyu
Comment 0 describes booting with the ArmVirtQemu guest firmware (aka edk2-aarch64) from a USB disk. The ArmVirtQemu guest firmware supports booting off of usb-storage, but with an intentionally narrow scope. Refer to the following commit message: f9c59fa44ae2 ("OvmfPkg/QemuBootOrderLib: recognize "usb-storage" devices in XHCI ports", 2017-09-22). https://github.com/tianocore/edk2/commit/f9c59fa44ae2 This upstream commit was mainly motivated for booting AARCH64 Windows install media, as it would only progress past a certain point when launched from usb-storage (not virtio-scsi, for example).
We discussed this BZ in the Virt-ARM team meeting this morning and took the decision to enable usb-storage for ARM.
No need for PM to chime in on the need for this feature. Laszlo's comment 10 is good enough for me. Clearing needinfo on Martin.
All we need now is qa_ack+ and ITM set.... I set DTM=24 as +2 essentially from the next DTM (02-Aug) - if the review is quick, then it could be done by 23.
Hello Andrew, I noticed that the latest rhel.9.0 qemu-kvm-6.0.0-10.el9 also does not support "usb-storage", bus usb-bus. Do we plan to fix it on rhel.9.0 beta too? Do I need to open a new bug to track it on rhel.9.0? QEMU emulator version 6.0.0 (qemu-kvm-6.0.0-10.el9) [root@gigabyte-r120-21 kar]# /usr/libexec/qemu-kvm -cpu host -device help | grep usb name "usb-host", bus usb-bus name "usb-hub", bus usb-bus name "usb-kbd", bus usb-bus name "usb-mouse", bus usb-bus name "usb-tablet", bus usb-bus
(In reply to Zhenyu Zhang from comment #17) > Hello Andrew, > > I noticed that the latest rhel.9.0 qemu-kvm-6.0.0-10.el9 also does not > support "usb-storage", bus usb-bus. > Do we plan to fix it on rhel.9.0 beta too? > Do I need to open a new bug to track it on rhel.9.0? > Yes, please.
(In reply to Andrew Jones from comment #18) > (In reply to Zhenyu Zhang from comment #17) > > Do I need to open a new bug to track it on rhel.9.0? > > Yes, please. Thanks for the quick reply. Clone this bug to Bug 1989601 on rhel.9.0.
Use the following version of the test pass, so set Test. Test Environment: Host Distro: RHEL-8.5.0-20210730.n.0 Host Kernel: 4.18.0-325.el8.aarch64 Qemu-kvm: qemu-kvm-6.0.0-27.module+el8.5.0+12121+c40c8708 edk2: edk2-aarch64-20210527gite1999b264f1f-1.el8.noarch [root@hpe-apache-cn99xx-06 home]# virt-install --connect qemu:///system --os-variant rhel8-unknown --arch aarch64 --disk /home/test/RHEL-8.5.0-20210730.n.0-aarch64-dvd1.iso,bus=usb --boot uefi --name avocado-vt-vm1 --memory 4096 --disk size=10 --network bridge=switch,model=virtio --import --noreboot --noautoconsole --serial pty --memballoon model=virtio --graphics vnc Starting install... Allocating 'avocado-vt-vm1.qcow2' | 10 GB 00:00:00 Domain creation completed. You can restart your domain by running: virsh --connect qemu:///system start avocado-vt-vm1 UsbBootExecCmd: Success to Exec 0x0 Cmd (Result = 1) BdsDxe: loading Boot0002 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:01.1:00.0-1" from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/USB(0x0,0x0) BdsDxe: starting Boot0002 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:01.1:00.0-1" from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/USB(0x0,0x0)
Set bug to VERIFIED according to Comment 21
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 (virt:av bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2021:4684