Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1097078

Summary: Win2012r2 guest bsod when boot image change from virtio-blk to virtio-scsi
Product: Red Hat Enterprise Linux 7 Reporter: ShupingCui <scui>
Component: virtio-winAssignee: Vadim Rozenfeld <vrozenfe>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 7.1CC: bcao, bsarathy, coli, hhuang, juzhang, michen, mkenneth, qzhang, rbalakri, rhod, scui, shuang, sluo, virt-maint, vrozenfe, xhan, xutian
Target Milestone: rcKeywords: TestBlocker
Target Release: 7.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-18 23:52:17 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:
Description Flags
screenshot none

Description ShupingCui 2014-05-13 06:28:00 UTC
Description of problem:
Install Win2012r2.x86_64 guest with virtio-scsi, then install virtio-blk driver after guest install successful.

Boot up guest with the drive which is virtio-blk as a system image, shutdown the guest and boot up guest with the drive which is virtio-scsi as a system image, it would fail with blue screen with error: INACCESSABLE_BOOT_DEVICE.

Version-Release number of selected component (if applicable):
2.6.32-460.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.425.el6.x86_64
virtio-win-1.6.8

How reproducible:
100%

Steps to Reproduce:
1. Install Win2012r2.x86_64 guest with virtio-scsi driver
/usr/bin/qemu-kvm \
    -name 'virt-tests-vm1' \
    -M rhel6.5.0  \
    -nodefaults  \
    -vga qxl  \
    -global qxl-vga.vram_size=33554432 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=05 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=06 \
    -drive id=drive_image1,if=none,cache=unsafe,snapshot=off,aio=native,file=/root/tests/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2012r2-64-virtio.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1 \
    -device virtio-net-pci,mac=9a:6a:6b:6c:6d:6e,id=idaSfanI,vectors=4,netdev=idDIQV3I,bus=pci.0,addr=07  \
    -netdev tap,id=idDIQV3I,vhost=on,vhostfd=23,fd=22  \
    -m 2048  \
    -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
    -cpu 'Penryn',hv_relaxed \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,media=cdrom,file=/root/tests/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/isos/ISO/Win2012R2/en_windows_server_2012_r2_x64_dvd_2707946.iso \
    -device ide-drive,id=cd1,drive=drive_cd1,bus=ide.0,unit=0 \
    -drive id=drive_winutils,if=none,snapshot=off,aio=native,media=cdrom,file=/root/tests/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/isos/windows/winutils.iso \
    -device ide-drive,id=winutils,drive=drive_winutils,bus=ide.0,unit=1 \
    -drive id=drive_virtio,if=none,snapshot=off,aio=native,media=cdrom,file=/root/tests/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/isos/windows/virtio-win-latest-signed.iso \
    -device ide-drive,id=virtio,drive=drive_virtio,bus=ide.1,unit=0 \
    -drive id=drive_fl,if=none,cache=unsafe,snapshot=off,readonly=off,aio=native,file=/root/tests/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2012r2-64/answer.vfd \
    -global isa-fdc.driveA=drive_fl \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -spice port=3000,password=123456,addr=0,image-compression=auto_glz,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=d,menu=off \
    -enable-kvm

2. Install virtio-blk driver after guest install successful.
3. Boot up guest with the drive which is virtio-blk as a system image:
/usr/bin/qemu-kvm \
    -name 'virt-tests-vm1' \
    -M rhel6.5.0  \
    -nodefaults  \
    -vga qxl  \
    -global qxl-vga.vram_size=33554432 \
    -drive id=drive_image1,if=none,cache=unsafe,snapshot=off,aio=native,file=/root/tests/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2012r2-64-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=06 \

4. shutdown the guest and boot up guest with the drive which is virtio-scsi as a system image:
/usr/bin/qemu-kvm \
    -name 'virt-tests-vm1' \
    -M rhel6.5.0  \
    -nodefaults  \
    -vga qxl  \
    -global qxl-vga.vram_size=33554432 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=06 \
    -drive id=drive_image1,if=none,cache=unsafe,snapshot=off,aio=native,file=/root/tests/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2012r2-64-virtio.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1 \


Actual results:
The image then could no boot with virtio-scsi as the sys image.

Expected results:
Booting guest should work normally.

Additional info:
Host cpu info:
processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz
stepping	: 10
cpu MHz		: 2000.000
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority
bogomips	: 5652.47
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Comment 1 ShupingCui 2014-05-13 06:28:48 UTC
Created attachment 895009 [details]
screenshot

Comment 3 ShupingCui 2014-05-13 07:03:03 UTC
can be reproduced on qemu-kvm-rhev-0.12.1.2-2.424.el6.

Comment 12 ShupingCui 2014-05-14 03:27:29 UTC
This bug will block out autotest testing, so set TestBlocker keyword.

Comment 18 Suqin Huang 2014-07-07 02:48:47 UTC
Hi Vadim,
As this bug block autotest acceptance testing, I'd like to know the process of this bug.

Thanks
Suqin

Comment 19 Vadim Rozenfeld 2014-07-07 03:50:58 UTC
(In reply to Suqin Huang from comment #18)
> Hi Vadim,
> As this bug block autotest acceptance testing, I'd like to know the process
> of this bug.
> 
> Thanks
> Suqin

Hi Suqin,

in the description section, step 2 it said  "2. Install virtio-blk driver after guest install successful." 
What kind of installation it was - software first (when we install driver first and then attach a new HW) or hardware first (when we install new HW first and then selecting an appropriate driver, following the new HW installation wizard's instructions) ?

Thanks,
Vadim.

Comment 20 ShupingCui 2014-07-07 05:38:14 UTC
(In reply to Vadim Rozenfeld from comment #19)
> (In reply to Suqin Huang from comment #18)
> > Hi Vadim,
> > As this bug block autotest acceptance testing, I'd like to know the process
> > of this bug.
> > 
> > Thanks
> > Suqin
> 
> Hi Suqin,
> 
> in the description section, step 2 it said  "2. Install virtio-blk driver
> after guest install successful." 
> What kind of installation it was - software first (when we install driver
> first and then attach a new HW) or hardware first (when we install new HW
> first and then selecting an appropriate driver, following the new HW
> installation wizard's instructions) ?
> 
> Thanks,
> Vadim.

Hi Vadim,

It's hardware first (when we install new HW first and then selecting an appropriate driver, following the new HW installation wizard's instructions).

Please let me know if you need more infos.

command line:
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/root/images/win2012-64r2-virtio.qcow2 \
    -device ide-hd,id=image1,drive=drive_image1,bus=ide.0,unit=0 \
    -drive id=drive_stg,if=none,cache=none,snapshot=off,aio=native,file=/root/images/storage.qcow2 \
    -device virtio-blk-pci,id=stg,drive=drive_stg,bus=pci.0,addr=06 \

Thanks,
Shuping

Comment 22 Vadim Rozenfeld 2014-07-07 21:36:48 UTC
(In reply to ShupingCui from comment #20)
> (In reply to Vadim Rozenfeld from comment #19)
> > (In reply to Suqin Huang from comment #18)
> > > Hi Vadim,
> > > As this bug block autotest acceptance testing, I'd like to know the process
> > > of this bug.
> > > 
> > > Thanks
> > > Suqin
> > 
> > Hi Suqin,
> > 
> > in the description section, step 2 it said  "2. Install virtio-blk driver
> > after guest install successful." 
> > What kind of installation it was - software first (when we install driver
> > first and then attach a new HW) or hardware first (when we install new HW
> > first and then selecting an appropriate driver, following the new HW
> > installation wizard's instructions) ?
> > 
> > Thanks,
> > Vadim.
> 
> Hi Vadim,
> 
> It's hardware first (when we install new HW first and then selecting an
> appropriate driver, following the new HW installation wizard's instructions).
> 
> Please let me know if you need more infos.
> 
> command line:
>     -drive
> id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/root/images/
> win2012-64r2-virtio.qcow2 \
>     -device ide-hd,id=image1,drive=drive_image1,bus=ide.0,unit=0 \
>     -drive
> id=drive_stg,if=none,cache=none,snapshot=off,aio=native,file=/root/images/
> storage.qcow2 \
>     -device virtio-blk-pci,id=stg,drive=drive_stg,bus=pci.0,addr=06 \
> 
> Thanks,
> Shuping

Thanks Shuping,
Let me check if software-first installation helps in this case. 
It will take me a couple of days to see if it works or not.

Best regards,
Vadim.

Comment 23 Ronen Hod 2014-08-10 09:45:19 UTC
Vadim will verify. It seems as if the installer needs to first install the drivers (to the drivers store), and only then do this.

Comment 24 Vadim Rozenfeld 2014-08-12 09:04:29 UTC
Well, it's not a virtio-scsi or virtio-blk driver problem.  Windows 8 and higher seems to be disabling third-party mini-port drivers. The following steps should be taken to bring them back:
1. Start VM with IDE or any other controlled which is still functional (IDE should be enable in any case).
2. Start cmd as Administrator and and set the machine to boot into Safe mode by typing "bcdedit /set {current} safeboot minimal"
3. Shutdown the VM.
4. Change the storage type.
5. VM shoul start "normaly".
6. Reset the bcdedit settings to allow the machine to boot into the Normal mode by typing "bcdedit /deletvalue {current} safeboot"
7. Reboot VM.

Best regards,
Vadim.

Comment 25 CongLi 2014-09-03 06:22:06 UTC
Thanks Vadim.

Hi scui,

Could you have a try according to comment 24? 
We need make sure the method in comment 24 works fine for us.

Thanks.

Comment 26 ShupingCui 2014-09-16 04:36:20 UTC
(In reply to Vadim Rozenfeld from comment #24)
> Well, it's not a virtio-scsi or virtio-blk driver problem.  Windows 8 and
> higher seems to be disabling third-party mini-port drivers. The following
> steps should be taken to bring them back:
> 1. Start VM with IDE or any other controlled which is still functional (IDE
> should be enable in any case).
> 2. Start cmd as Administrator and and set the machine to boot into Safe mode
> by typing "bcdedit /set {current} safeboot minimal"
> 3. Shutdown the VM.
> 4. Change the storage type.
> 5. VM shoul start "normaly".
> 6. Reset the bcdedit settings to allow the machine to boot into the Normal
> mode by typing "bcdedit /deletvalue {current} safeboot"
> 7. Reboot VM.
> 
> Best regards,
> Vadim.

Hi Vadim,

Still doesn't work for me, for details:
1. install win2012r2 guest with virtio-scsi suing virtio-win-prewhql-0.1-91.iso
2. Install virtio-blk driver after guest install successful.
3. Start VM with IDE or any other controlled which is still functional (IDE should be enable in any case).
4. Start cmd as Administrator and and set the machine to boot into Safe mode by typing "bcdedit /set {current} safeboot minimal"
5. Shutdown the VM.
6. Change the storage type to virtio-blk.
7. VM shoul start "normaly".
8. Reset the bcdedit settings to allow the machine to boot into the Normal mode by typing "bcdedit /deletevalue {current} safeboot"
9. Reboot VM.
    guest reboot successfully.

10. Shutdown the VM.
11. boot guest with virtio-scsi
    guest bsod with error: INACCESSABLE_BOOT_DEVICE.

Comment 27 Vadim Rozenfeld 2014-09-16 08:42:59 UTC
Steps 4..9 should be repeated every time we change disk type (except for IDE of cause).

Thanks,
Vadim.

Comment 28 ShupingCui 2014-09-17 02:02:38 UTC
(In reply to Vadim Rozenfeld from comment #27)
> Steps 4..9 should be repeated every time we change disk type (except for IDE
> of cause).
> 
> Thanks,
> Vadim.

Hi Vadim,

You're right, need to repeat steps 3..9 for every time we need to change disk type.


Thanks,
Shuping

Comment 29 Vadim Rozenfeld 2014-09-17 07:22:05 UTC
(In reply to ShupingCui from comment #28)
> (In reply to Vadim Rozenfeld from comment #27)
> > Steps 4..9 should be repeated every time we change disk type (except for IDE
> > of cause).
> > 
> > Thanks,
> > Vadim.
> 
> Hi Vadim,
> 
> You're right, need to repeat steps 3..9 for every time we need to change
> disk type.
> 
> 
> Thanks,
> Shuping

Great.
Can we close it as NOTABUG?
Thanks,
Vadim.

Comment 30 Vadim Rozenfeld 2014-11-01 11:30:47 UTC
*** Bug 1046275 has been marked as a duplicate of this bug. ***