Bug 1662418 - Windows installation got stuck with vioscsi and scsi-block on a uas drive
Summary: Windows installation got stuck with vioscsi and scsi-block on a uas drive
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virtio-win
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vadim Rozenfeld
QA Contact: Peixiu Hou
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-28 10:12 UTC by Tom Yan
Modified: 2019-01-15 10:19 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-15 10:19:38 UTC


Attachments (Terms of Use)
error message when install guest os (31.79 KB, image/png)
2019-01-07 09:40 UTC, Peixiu Hou
no flags Details

Description Tom Yan 2018-12-28 10:12:24 UTC
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

Comment 1 Vadim Rozenfeld 2018-12-28 11:33:38 UTC
Can QA try reproducing this issue?

Thanks,
Vadim.

Comment 2 Peixiu Hou 2018-12-29 10:21:35 UTC
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

Comment 3 Peixiu Hou 2019-01-07 08:51:28 UTC
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

Comment 4 Tom Yan 2019-01-07 09:15:58 UTC
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.

Comment 5 Peixiu Hou 2019-01-07 09:40:38 UTC
Created attachment 1518935 [details]
error message when install guest os

Comment 6 Peixiu Hou 2019-01-07 09:44:22 UTC
(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

Comment 7 Tom Yan 2019-01-07 10:38:41 UTC
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.

Comment 8 Peixiu Hou 2019-01-08 03:04:41 UTC
(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

Comment 9 Tom Yan 2019-01-11 03:49:11 UTC
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.

Comment 10 Tom Yan 2019-01-14 16:43:23 UTC
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?

Comment 11 Tom Yan 2019-01-15 10:19:38 UTC
Never mind, I can't reproduce it with the same hardware and same command anymore, with any version of vioscsi. Closing.


Note You need to log in before you can comment on or make changes to this bug.