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 1549455

Summary: Event ID: 158 is logged on Win10/WS2016 when two or more virtio-blk disks attached to VM
Product: Red Hat Enterprise Linux 7 Reporter: Vadim Rozenfeld <vrozenfe>
Component: virtio-winAssignee: Vadim Rozenfeld <vrozenfe>
virtio-win sub component: virtio-win-prewhql QA Contact: Virtualization Bugs <virt-bugs>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: ailan, aliang, coli, jherrman, lijin, michen, phou, vrozenfe, wyu
Version: 7.6   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
When two or more virtio-blk devices were connected to a Windows 10 or a Windows Server 2016 guest at the same time, the guest system reported "event ID:158" errors. With this update, each virtio-blk device reports a unique ID to the affected guest systems, which ensures that the described errors no longer occur.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 16:21:49 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:

Description Vadim Rozenfeld 2018-02-27 06:58:04 UTC 
Description of problem:
Event ID: 158 is logged on Win10/WS2016 when two or more virtio-blk disks attached to VM

Version-Release number of selected component (if applicable):


How reproducible:
100% 

Steps to Reproduce:
1.create VM with two or more vitio-blk disks (no matter if one of them system or not)
2. Open Event Viewer, go to Windows Logs, System
3. Check Event ID column for event 158

Actual results:
Event Id 158 will be logged even if serial number is explicitly specified in command line and diskpart.exe and mountvol.exe display unique disk ids for different disks.



Expected results:
Event Id 158 should not be logged on a properly working system.

Additional info:
Comment 2 Vadim Rozenfeld 2018-02-27 07:06:06 UTC 
Initially the problem was reported by community members:

https://github.com/virtio-win/kvm-guest-drivers-windows/issues/171#issuecomment-366491824
Comment 3 Peixiu Hou 2018-02-27 09:49:41 UTC 
Reproduced this bug under localhost, tried with win2016 guest, steps as comment#0.

Boot command:
/usr/libexec/qemu-kvm -name avocado-vt-vm1 -sandbox off -machine q35 -nodefaults -vga std -device i82801b11-bridge,id=dmi2pci_bridge,bus=pcie.0,addr=0x2 -device pci-bridge,id=pci_bridge,bus=dmi2pci_bridge,addr=0x1,chassis_nr=1 -device pvpanic,ioport=0x505,id=idymSH2J -device ich9-usb-ehci1,id=usb1,addr=0x1d.7,multifunction=on,bus=pcie.0 -device ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=0x1d.0,firstport=0,bus=pcie.0 -device ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=0x1d.2,firstport=2,bus=pcie.0 -device ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=0x1d.4,firstport=4,bus=pcie.0 -device pcie-root-port,id=pcie.0-root-port-3,slot=3,chassis=3,addr=0x3,bus=pcie.0 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie.0-root-port-3,addr=0x0 -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=win2016-64-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image1,bootindex=0 -device pcie-root-port,id=pcie.0-root-port-4,slot=4,chassis=4,addr=0x4,bus=pcie.0 -device virtio-net-pci,mac=9a:ee:ef:f0:f1:f2,id=idpLQXuZ,vectors=4,netdev=idcK7vPy,bus=pcie.0-root-port-4,addr=0x0 -netdev tap,id=idcK7vPy,vhost=on -m 2046 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 -cpu SandyBridge,+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time -drive id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/usr/share/virtio-win/virtio-win.iso -device scsi-cd,id=cd1,drive=drive_cd1 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -vnc :0 -rtc base=localtime,clock=host,driftfix=slew -boot menu=off,strict=off,order=cdn,once=c -enable-kvm -monitor stdio -drive file=data1.raw,if=none,id=drive-virtio0-0-1,format=raw,serial=mike_cao,cache=none -device virtio-blk-pci,drive=drive-virtio0-0-1,id=virtio0-0-1,scsi=off -drive file=data2.raw,if=none,id=drive-virtio0-0-2,format=raw,serial=mike_cao,cache=none -device virtio-blk-pci,drive=drive-virtio0-0-2,id=virtio0-0-2,scsi=off

Used versions:
kernel-3.10.0-836.el7.x86_64
qemu-kvm-rhev-2.10.0-18.el7.x86_64
seabios-1.10.2-5.el7.x86_64
virtio-win-1.9.4-2.el7.noarch

Best Regards~
Peixiu
Comment 4 Vadim Rozenfeld 2018-03-06 07:03:10 UTC 
Please give a try to viostor driver from the latest (b148) build 
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=659785

Thanks,
Vadim.
Comment 10 Peixiu Hou 2018-03-06 09:09:38 UTC 
(In reply to Vadim Rozenfeld from comment #4)
> Please give a try to viostor driver from the latest (b148) build 
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=659785
> 
Hi vadim,

I tried with the latest build 148, it also can be reproduced. 
Tested on win2016. Uninstall all 145 driver files first, then install 148 viostor driver, also hit 158 Event log. 
Other steps as comment#0, used kernel/qemu/seabios versions as comment#3,

Best Regards~
Peixiu

> Thanks,
> Vadim.
Comment 11 Vadim Rozenfeld 2018-03-06 11:33:30 UTC 
(In reply to Peixiu Hou from comment #10)
> (In reply to Vadim Rozenfeld from comment #4)
> > Please give a try to viostor driver from the latest (b148) build 
> > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=659785
> > 
> Hi vadim,
> 
> I tried with the latest build 148, it also can be reproduced. 
> Tested on win2016. Uninstall all 145 driver files first, then install 148
> viostor driver, also hit 158 Event log. 

Did you restart (not shutdown) the VM after updating the driver?

Thanks,
Vadim.

> Other steps as comment#0, used kernel/qemu/seabios versions as comment#3,
> 
> Best Regards~
> Peixiu
> 
> > Thanks,
> > Vadim.
Comment 12 Peixiu Hou 2018-03-07 09:48:39 UTC 
(In reply to Vadim Rozenfeld from comment #11)
> (In reply to Peixiu Hou from comment #10)
> > (In reply to Vadim Rozenfeld from comment #4)
> > > Please give a try to viostor driver from the latest (b148) build 
> > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=659785
> > > 
> > Hi vadim,
> > 
> > I tried with the latest build 148, it also can be reproduced. 
> > Tested on win2016. Uninstall all 145 driver files first, then install 148
> > viostor driver, also hit 158 Event log. 
> 
> Did you restart (not shutdown) the VM after updating the driver?
> 
I tried without restart and with restart vm after updating the driver, both reproduced this bug.

> Thanks,
> Vadim.
> 
> > Other steps as comment#0, used kernel/qemu/seabios versions as comment#3,
> > 
> > Best Regards~
> > Peixiu
> > 
> > > Thanks,
> > > Vadim.
Comment 13 Vadim Rozenfeld 2018-03-07 11:05:50 UTC 
(In reply to Peixiu Hou from comment #12)
> (In reply to Vadim Rozenfeld from comment #11)
> > (In reply to Peixiu Hou from comment #10)
> > > (In reply to Vadim Rozenfeld from comment #4)
> > > > Please give a try to viostor driver from the latest (b148) build 
> > > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=659785
> > > > 
> > > Hi vadim,
> > > 
> > > I tried with the latest build 148, it also can be reproduced. 
> > > Tested on win2016. Uninstall all 145 driver files first, then install 148
> > > viostor driver, also hit 158 Event log. 
> > 
> > Did you restart (not shutdown) the VM after updating the driver?
> > 
> I tried without restart and with restart vm after updating the driver, both
> reproduced this bug.

is the qemu cli the same as mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=1549455#c3? If so, then you have to specify different serial names for each viostor attached drive (or don't specify serial name at all, in this case viostor driver should be able to generate it by itself)

Best,
Vadim.
  
> 
> > Thanks,
> > Vadim.
> > 
> > > Other steps as comment#0, used kernel/qemu/seabios versions as comment#3,
> > > 
> > > Best Regards~
> > > Peixiu
> > > 
> > > > Thanks,
> > > > Vadim.
Comment 14 Peixiu Hou 2018-03-08 01:38:16 UTC 
(In reply to Vadim Rozenfeld from comment #13)
> (In reply to Peixiu Hou from comment #12)
> > (In reply to Vadim Rozenfeld from comment #11)
> > > (In reply to Peixiu Hou from comment #10)
> > > > (In reply to Vadim Rozenfeld from comment #4)
> > > > > Please give a try to viostor driver from the latest (b148) build 
> > > > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=659785
> > > > > 
> > > > Hi vadim,
> > > > 
> > > > I tried with the latest build 148, it also can be reproduced. 
> > > > Tested on win2016. Uninstall all 145 driver files first, then install 148
> > > > viostor driver, also hit 158 Event log. 
> > > 
> > > Did you restart (not shutdown) the VM after updating the driver?
> > > 
> > I tried without restart and with restart vm after updating the driver, both
> > reproduced this bug.
> 
> is the qemu cli the same as mentioned at
> https://bugzilla.redhat.com/show_bug.cgi?id=1549455#c3? If so, then you have
> to specify different serial names for each viostor attached drive (or don't
> specify serial name at all, in this case viostor driver should be able to
> generate it by itself)
> 
Hi vadim,

Yes, the qemu cli same as comment#3, thanks for your point~

Reproduced this bug on build 145 with different disk serial name.
Verified this bug on build 148 with different disk serial name, not hit 158 Event log.

Thanks a lot~
Peixiu
Comment 17 errata-xmlrpc 2018-10-30 16:21:49 UTC 
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://access.redhat.com/errata/RHBA-2018:3413
Comment 18 Yu Wang 2019-11-19 03:20:57 UTC 
Hi Vadim,

I have a detailed question for this bug, for other guests (win7,win8,win2012), it also report "Event ID: 158 " for this bug ?
Or it report other eventid, what is the id?
Or this check only suitable for win2016/win10/win2019?

Thanks
Yu Wang
Comment 19 Vadim Rozenfeld 2019-11-19 04:37:45 UTC 
(In reply to Yu Wang from comment #18)
> Hi Vadim,
> 
> I have a detailed question for this bug, for other guests
> (win7,win8,win2012), it also report "Event ID: 158 " for this bug ?
> Or it report other eventid, what is the id?
> Or this check only suitable for win2016/win10/win2019?
> 
> Thanks
> Yu Wang

Hi Tu Wang,
According to MS ( https://support.microsoft.com/en-us/help/2983588/event-id-158-is-logged-for-identical-disk-guids )
this problem /Event id applied to the following versions:
Windows 10, version 1909
Windows 10, version 1809
Windows 10, version 1803
Windows 10, version 1709
Windows 10, version 1703
Windows 10, version 1607
Windows 10
Windows 8.1 Enterprise 
Windows 8.1 Pro 
Windows 8.1

Which I believe is absolutely true, since I never seen previous
versions paying too much attention to VPD page 0x83.

All the best,
Vadim.
Comment 20 Yu Wang 2019-11-19 05:43:08 UTC 
(In reply to Vadim Rozenfeld from comment #19)
> (In reply to Yu Wang from comment #18)
> > Hi Vadim,
> > 
> > I have a detailed question for this bug, for other guests
> > (win7,win8,win2012), it also report "Event ID: 158 " for this bug ?
> > Or it report other eventid, what is the id?
> > Or this check only suitable for win2016/win10/win2019?
> > 
> > Thanks
> > Yu Wang
> 
> Hi Tu Wang,
> According to MS (
> https://support.microsoft.com/en-us/help/2983588/event-id-158-is-logged-for-
> identical-disk-guids )
> this problem /Event id applied to the following versions:
> Windows 10, version 1909
> Windows 10, version 1809
> Windows 10, version 1803
> Windows 10, version 1709
> Windows 10, version 1703
> Windows 10, version 1607
> Windows 10
> Windows 8.1 Enterprise 
> Windows 8.1 Pro 
> Windows 8.1
> 
> Which I believe is absolutely true, since I never seen previous
> versions paying too much attention to VPD page 0x83.
> 
> All the best,
> Vadim.

Got it , thanks a lot