Description of problem: I am having problem passing-through uas (usb attached scsi) drive again with vioscsi (virtio-scsi-pci + scsi-block). The problem is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1277060, but instead of getting stuck at the drive loading stage, it stuck at the very beginning when the installation begins (first stage stuck at 0% with the drive's led blinking but without any I/O according to iostat). I cannot kill qemu by Ctrl+C in this case either unless I unplug the drive after that. And after I replug the drive and check with lsblk -f, it appears that the formation of the smaller (Recovery and EFI) partition has been done, but that of the big main/system partition could not be done (FYR, the drive is 256GB). The uas bridge support UNMAP->TRIM translation, if that could matter. Version-Release number of selected component (if applicable): The latest working (iso) version appears to be 0.1.140. Neither 0.1.141 (stable) or 0.1.160 (latest) seem to work. How reproducible: Apparently always Steps to Reproduce: This is the full command I ran: qemu-system-x86_64 -enable-kvm -cpu host,kvm=off -smp cores=4 -m 8G -drive file=/dev/sdb,if=none,format=raw,cache=none,aio=native,id=sys -device virtio-scsi-pci -device scsi-block,drive=sys --bios /usr/share/ovmf/x64/OVMF_CODE.fd -rtc base=localtime -net nic -net bridge,br=bridge0 -drive file=/storage/17763.107.101029-1455.rs5_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_en-us.iso,media=cdrom -drive file=/storage/virtio-win-0.1.1XX.iso,media=cdrom
Can QA try reproducing this issue? Thanks, Vadim.
OK, trying to reproduce it, but has not get the final result, will update here once get it. BTW, Because we are going to have New Year's Day, will update it after holidays, thanks for understanding~ Best Regards~ Peixiu
Hi all, Due to we have not uas drive device, follows tests used LIO-OGR drive device replaced. Tested on rhel7.6 host, hit similar issue, but the guest not hang, instead with error "Windows cannot install requied files. The file may be corrupt or missing. Make sure all files required for installation are available and restart the installation. Error Code:0X80070570". used versions: kernel-3.10.0-931.el7.x86_64 qemu-kvm-rhev-2.12.0-10.el7.x86_64 virtio-win-prewhql-160 OVMF-20180508-3.gitee3198e672e2.el7.noarch seabios-bin-1.10.2-3.el7_4.1.noarch commands as: /usr/libexec/qemu-kvm \ -name win2016-ovmf \ -M q35 \ -cpu SandyBridge,+kvm_pv_unhalt,hv_spinlocks=0x1fff,hv_relaxed,hv_vapic,hv_time \ -enable-kvm \ -m 2G \ -smp 4,maxcpus=8 -cpu SandyBridge \ -rtc base=localtime,clock=host,driftfix=slew \ -uuid a2e4360e-7009-4d0a-a729-6bceb50c9121 \ -object iothread,id=thread0 \ -device pcie-root-port,bus=pcie.0,id=root1.0,slot=1 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=root1.0,iothread=thread0,num_queues=4 \ -drive file=/dev/sdd,id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=raw \ -device scsi-block,id=image1,drive=drive_image1,bootindex=1 \ -drive file=/home/kvm_autotest_root/iso/ISO/Win10/en_windows_10_business_editions_version_1803_updated_march_2018_x64_dvd_12063333.iso,media=cdrom,id=cdrom,if=none -device ide-drive,drive=cdrom,bootindex=0 \ -device piix3-usb-uhci,id=usb \ -device usb-tablet,id=tablet0 \ -k en-us \ -vnc 0.0.0.0:1 \ -vga std \ -monitor stdio \ -qmp tcp:0:4446,server,nowait \ -boot menu=on \ -device pcie-root-port,bus=pcie.0,id=root2.0,slot=2 \ -netdev tap,script=/etc/qemu-ifup,id=hostnet0,vhost=on,queues=4 \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:e2:52:22:16:03,mq=on,vectors=10,bus=root2.0 \ -cdrom /home/kvm_autotest_root/iso/windows/virtio-win-prewhql-0.1-160.iso \ -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \ -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \ Hit error picture please refer to attachment. isolation: 1. Tested with q35+ovmf, make sure with efi mode, match with comment#0 command "--bios /usr/share/ovmf/x64/OVMF_CODE.fd(I cannot boot guest up with this command directly)", hit Error Code:0X80070570. 2. Tested with q35+seabios(meas not efi mode), also hit Error Code:0X80070570. 3. Tested with q35+ovmf and virtio-win-prewhql-140/141, also hit Error Code:0X80070570. Best Regards~ Peixiu
Does the error you hit occurs *starting with* vioscsi in 0.1.141 ISO though? Wonder if they are actually related. Not seeing any attachment btw.
Created attachment 1518935 [details] error message when install guest os
(In reply to Tom Yan from comment #4) > Does the error you hit occurs *starting with* vioscsi in 0.1.141 ISO though? > Wonder if they are actually related. > > Not seeing any attachment btw. sorry for attachment, has updated, I tried with 0.1.140, also hit same error. and I also tried on rhel8 host, hit qemu core dump, I filed a new bug1663828, not sure if same root cause~ Best Regards~ Peixiu
I am with qemu 3.1.0 on Arch Linux btw. vioscsi in 0.1.140 iso has been working perfectly well for me (heavy gaming / video downloading / etc.). I'm starting to wonder if it has something to do with how the driver is compiled (platform / compiler / configuration / etc.). Last time similar problem shows up (https://bugzilla.redhat.com/show_bug.cgi?id=1277060) we can't really find a commit that seem to be relevant either.
(In reply to Tom Yan from comment #7) > I am with qemu 3.1.0 on Arch Linux btw. vioscsi in 0.1.140 iso has been > working perfectly well for me (heavy gaming / video downloading / etc.). > > I'm starting to wonder if it has something to do with how the driver is > compiled (platform / compiler / configuration / etc.). Last time similar > problem shows up (https://bugzilla.redhat.com/show_bug.cgi?id=1277060) we > can't really find a commit that seem to be relevant either. It seems we hit not the same issue~ I also tried test with virtio-win-prewhql-140 and qemu 3.1.0 on x86 Linux, hit qemu core dump again, did not hit guest hang when install started. Guest os installation progress bar can get 100%, just after reboot, qemu core dump occurred. Both with blockdev format command and drive format command hit same result. And both test with q35+ovmf. blockdev format commands as: -object iothread,id=thread0 \ -device pcie-root-port,bus=pcie.0,id=root1.0,slot=1 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=root1.0,iothread=thread0,num_queues=4 \ -blockdev driver=host_device,cache.direct=off,cache.no-flush=on,filename=/dev/sdd,node-name=my_file \ -blockdev driver=raw,node-name=my,file=my_file \ -device scsi-block,drive=my,bus=virtio_scsi_pci0.0 \ -drive file=/home/kvm_autotest_root/iso/ISO/Win2019/en_windows_server_2019_x64_dvd_4cb967d8.iso,media=cdrom,id=cdrom,if=none -device ide-drive,drive=cdrom,bootindex=0 \ -cdrom virtio-win-prewhql-0.1-140.iso \ -M q35 \ -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \ -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \ drive format commands as: -object iothread,id=thread0 \ -device pcie-root-port,bus=pcie.0,id=root1.0,slot=1 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=root1.0,iothread=thread0,num_queues=4 \ -drive file=/dev/sdd,id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=raw \ -device scsi-block,id=image1,drive=drive_image1,bootindex=1 \ -drive file=/home/kvm_autotest_root/iso/ISO/Win2019/en_windows_server_2019_x64_dvd_4cb967d8.iso,media=cdrom,id=cdrom,if=none \ -device ide-drive,drive=cdrom,bootindex=0 \ -cdrom virtio-win-prewhql-0.1-140.iso \ -M q35 \ -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \ -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \ Best Regards~ Peixiu
Just tried to test out scsi-generic with my current Windows installation (with vioscsi driver from 0.1.140) and it stuck at the boot splash, the "wheel" keeps spinning and the LED of my drive keeps blinking, qemu also couldn't be killed until I unplug my drive. Wonder if this gives some hint on the cause of the issue.
Can someone at least tell me the respective commit id of 0.1.140 and 0.1.141 so that I can do a bisect?
Never mind, I can't reproduce it with the same hardware and same command anymore, with any version of vioscsi. Closing.