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 1325078 - Add TargetOSVersion to driver inf files
Summary: Add TargetOSVersion to driver inf files
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.3
Hardware: Unspecified
OS: Windows
unspecified
high
Target Milestone: rc
: ---
Assignee: Ladi Prosek
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1328181
TreeView+ depends on / blocked
 
Reported: 2016-04-08 07:17 UTC by Ladi Prosek
Modified: 2016-11-04 08:53 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, it was possible to install incorrect versions of virtio drivers, especially when running an older Windows operating system. This sometimes caused the guest to terminate unexpectedly with a stop error, also known as the "Blue Screen of Death", if the particular driver and Windows versions were incompatible. This update adds target OS version information to driver files, which enables Windows to automatically select the best driver when pointed to the root of the virtio-win CD image. Installing an incompatible driver version manually is also no longer possible, as Windows now presents the user with an error message if installation is attempted.
Clone Of:
: 1328181 (view as bug list)
Environment:
Last Closed: 2016-11-04 08:53:15 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2609 0 normal SHIPPED_LIVE virtio-win bug fix and enhancement update 2016-11-03 15:27:12 UTC

Description Ladi Prosek 2016-04-08 07:17:29 UTC 
Description of problem:
Drivers do not currently declare their minimum supported Windows version and can be installed on an older OS than intended without any warnings.

Even worse, the common practice seems to be to point Windows to the root of the virtio-win ISO, in which case it will pick one of the drivers for the user, most likely kind of randomly.

Steps to Reproduce:
1. When installing a driver, point Windows to the root of the ISO / driver distribution and check "Search in subfolders".

Actual results:
The installed driver does not match Windows version.

Expected results:
The installed driver matches Windows version.

Additional info:
To verify that the right version of the driver has been installed, use for example:

fc \windows\system32\drivers\viostor.sys D:\viostor\w7\amd64\viostor.sys
Comment 8 Yu Wang 2016-06-13 07:50:12 UTC 
Reproduced this bug on build 106
Verified this bug on  virtio-win10-prewhql-16

Test guest OS
*win7-32
*win2012R2

Test Driver
*viostor.sys
*vioscsi.sys
*netkvm.sys

Steps as comment#0

Result:
The installed driver matches Windows version.

Above all, this bug has been fixed.

Thanks
Yu Wang
Comment 9 Yu Wang 2016-08-01 08:06:49 UTC 
Hi,

Tested virtio-win-prewhql-124 balloon driver on win8-32 and win2012R2, the default installed driver should be in "win8" folder, but it actually installed the driver in "win7" folder.

Thanks
Yu Wang
Comment 10 Ladi Prosek 2016-08-01 08:54:13 UTC 
Hi Yu Wang,

Nice catch! All balloon and vioserial drivers in 124 have version 62.73.104.12400 and 63.73.104.12400, respectively. Not related to TargetOSVersion but it makes them all look the same to the Windows driver selection process. Looking into it.

Thanks!
Ladi
Comment 12 Yu Wang 2016-08-03 09:52:48 UTC 
Hi Ladi,

Tested virtio-win-prewhql-124 vioscsi driver on win7-32 and win2008R2, the default installed driver should be in "wlh" folder, but it actually installed the driver in "win7" folder.

Thanks
Yu Wang
Comment 13 Ladi Prosek 2016-08-03 12:28:00 UTC 
Hi Yu Wang,

(In reply to Yu Wang from comment #12)
> Hi Ladi,
> 
> Tested virtio-win-prewhql-124 vioscsi driver on win7-32 and win2008R2, the
> default installed driver should be in "wlh" folder, but it actually
> installed the driver in "win7" folder.

This looks by design to me. win2008R2 and win7-32 are both NT6.1 built on the Win7 kernel. Checked the driver mapping table and sure enough, it lists "wlh" as the right folder for these systems. Vadim, what's the reason for that? Do we really not want to use vioscsi from the "win7" folder anywhere?
Comment 15 lijin 2016-08-08 06:23:00 UTC 
Hi Vadim,

What's the plan of developers?

In https://bugzilla.redhat.com/show_bug.cgi?id=1352556#c20,seems scsi driver will separated into two folders.

Do you intend to change the driver mapping tables of other drivers as well as Ladi suggested?

BTW,qe noticed there is a new win8.1 folder in recent builds and there is only netkvm driver in this folder.What's this folder for?
Comment 16 Vadim Rozenfeld 2016-08-08 09:52:43 UTC 
(In reply to lijin from comment #15)
> Hi Vadim,
> 
> What's the plan of developers?
> 
> In https://bugzilla.redhat.com/show_bug.cgi?id=1352556#c20,seems scsi driver
> will separated into two folders.
>

Hi Li Jin,
do you mean https://mojo.redhat.com/docs/DOC-130115 created by Mike some time ago?
 
> Do you intend to change the driver mapping tables of other drivers as well
> as Ladi suggested?
> 
> BTW,qe noticed there is a new win8.1 folder in recent builds and there is
> only netkvm driver in this folder.What's this folder for?

IIUC, two drivers in Win8 and Win8.1 should be the same but stamped with different kernel version numbers. Yan, can you please comment on this question?

Thanks,
Vadim.
Comment 17 lijin 2016-08-08 10:24:48 UTC 
(In reply to Vadim Rozenfeld from comment #16)
> (In reply to lijin from comment #15)
> > Hi Vadim,
> > 
> > What's the plan of developers?
> > 
> > In https://bugzilla.redhat.com/show_bug.cgi?id=1352556#c20,seems scsi driver
> > will separated into two folders.
> >
> 
> Hi Li Jin,
> do you mean https://mojo.redhat.com/docs/DOC-130115 created by Mike some
> time ago?

Yes,if dev plan to change the driver map,QE will modify the table and change driver installation during test.

> > Do you intend to change the driver mapping tables of other drivers as well
> > as Ladi suggested?
> > 
> > BTW,qe noticed there is a new win8.1 folder in recent builds and there is
> > only netkvm driver in this folder.What's this folder for?
> 
> IIUC, two drivers in Win8 and Win8.1 should be the same but stamped with
> different kernel version numbers. Yan, can you please comment on this
> question?

May I know why only netkvm driver is there,what about other drivers?

> Thanks,
> Vadim.
Comment 18 Vadim Rozenfeld 2016-08-09 03:23:51 UTC 
(In reply to lijin from comment #17)
> (In reply to Vadim Rozenfeld from comment #16)
> > (In reply to lijin from comment #15)
> > > Hi Vadim,
> > > 
> > > What's the plan of developers?
> > > 
> > > In https://bugzilla.redhat.com/show_bug.cgi?id=1352556#c20,seems scsi driver
> > > will separated into two folders.
> > >
> > 
> > Hi Li Jin,
> > do you mean https://mojo.redhat.com/docs/DOC-130115 created by Mike some
> > time ago?
> 
> Yes,if dev plan to change the driver map,QE will modify the table and change
> driver installation during test.
> 

Then for virtio-scsi it will be better to split between Vista/WS2008 and Win7/WS2008R2

> > > Do you intend to change the driver mapping tables of other drivers as well
> > > as Ladi suggested?
> > > 
> > > BTW,qe noticed there is a new win8.1 folder in recent builds and there is
> > > only netkvm driver in this folder.What's this folder for?
> > 
> > IIUC, two drivers in Win8 and Win8.1 should be the same but stamped with
> > different kernel version numbers. Yan, can you please comment on this
> > question?
> 
> May I know why only netkvm driver is there,what about other drivers?
> 
speaking about viostor and vioscsi there is no difference between Win8.1 and Win8 builds. I believe that above statement is also relevant to vioserial and balloon. If Yan agree, we can remove (at least for now) building Win8.1 targets from the build script.

Best regards,
Vadim.

> > Thanks,
> > Vadim.
Comment 19 lijin 2016-08-09 05:15:55 UTC 
(In reply to Vadim Rozenfeld from comment #18)

> Then for virtio-scsi it will be better to split between Vista/WS2008 and
> Win7/WS2008R2

so for win2008,we will install scsi driver in "Wlh" folder;for win7&win2008R2,we will install scsi driver in "Win7" folder.

Thanks.
Comment 20 Yu Wang 2016-08-19 03:02:12 UTC 
Hi Amnon and Ladi,

QE test this bug on win7,win2008R2 and win2008 w/ balloon device, according to mapping table:https://mojo.redhat.com/docs/DOC-130115.the default installed driver should be in "Wnet"and "Wxp" folder, but it actually installed the driver in "win7" and "wlh"folder. 

QE wonder that whether other drivers also change the default path, please help to confirm with Yan and Vadim and check whether our mapping table is right, if not please help to correct it, if yes, please fix this bug according this mapping table.


Thanks
Yu Wang
Comment 21 Ladi Prosek 2016-08-19 07:32:48 UTC 
Hi Yu Wang,

(In reply to Yu Wang from comment #20)
> Hi Amnon and Ladi,
> 
> QE test this bug on win7,win2008R2 and win2008 w/ balloon device, according
> to mapping table:https://mojo.redhat.com/docs/DOC-130115.the default
> installed driver should be in "Wnet"and "Wxp" folder, but it actually
> installed the driver in "win7" and "wlh"folder. 
> 
> QE wonder that whether other drivers also change the default path, please
> help to confirm with Yan and Vadim and check whether our mapping table is
> right, if not please help to correct it, if yes, please fix this bug
> according this mapping table.

I believe that the mapping table is outdated and should be fixed. I'll talk to Vadim about it. Either way, the fix won't change. If we decide to still use the old mapping, there won't be no Win7 and Wlh balloon driver in the RPM so the discrepancy you're seeing with the raw build just won't be possible.

One question for you: are you guys planning to run the balloon driver in the Win7 and Wlh folder through WHQL? Saving money and testing efforts would be a valid reason why stick with the current mapping. So if you test it anyway, we may as well ship it and change the table. But if you've been ignoring the Win7 and Wlh builds (maybe aside from this bug?), then it would make more sense to keep the status quo.

Thanks!
Ladi
Comment 22 lijin 2016-08-19 08:10:50 UTC 
(In reply to Ladi Prosek from comment #21)
> Hi Yu Wang,
> 
> (In reply to Yu Wang from comment #20)
> > Hi Amnon and Ladi,
> > 
> > QE test this bug on win7,win2008R2 and win2008 w/ balloon device, according
> > to mapping table:https://mojo.redhat.com/docs/DOC-130115.the default
> > installed driver should be in "Wnet"and "Wxp" folder, but it actually
> > installed the driver in "win7" and "wlh"folder. 
> > 
> > QE wonder that whether other drivers also change the default path, please
> > help to confirm with Yan and Vadim and check whether our mapping table is
> > right, if not please help to correct it, if yes, please fix this bug
> > according this mapping table.
> 
> I believe that the mapping table is outdated and should be fixed. I'll talk
> to Vadim about it. Either way, the fix won't change. If we decide to still
> use the old mapping, there won't be no Win7 and Wlh balloon driver in the
> RPM so the discrepancy you're seeing with the raw build just won't be
> possible.
> 
> One question for you: are you guys planning to run the balloon driver in the
> Win7 and Wlh folder through WHQL?

Hi Ladi,

This depends on developers.If developers think qe should use the updated mapped drivers,of course,qe will test with them.

We ask the question because we need to confirm with you which folder we should use as all kvm qe install virtio-win drivers according to the mapping table in https://mojo.redhat.com/docs/DOC-130115.

In the old mapping table,netkvm driver involves Vista folder,balloon/serial driver involve Wxp,Wnet folders.

There is no one notify us about driver mapping changes.We just hope we are testing the correct driver file.

So what we want to do is to confirm with all developers that all virtio-win drivers mapping are changed according to windows kernel as following?

Wlh - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit , \ amd64 - 64bit)
Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)

If all developers confirmed the changes,qe will update the mapping table,and test with the correct drivers.
Comment 23 Ladi Prosek 2016-08-19 10:16:03 UTC 
(In reply to lijin from comment #22)
> There is no one notify us about driver mapping changes.We just hope we are
> testing the correct driver file.
> 
> So what we want to do is to confirm with all developers that all virtio-win
> drivers mapping are changed according to windows kernel as following?
> 
> Wlh - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
> Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
> Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit ,
> \ amd64 - 64bit)
> Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)
> 
> If all developers confirmed the changes,qe will update the mapping table,and
> test with the correct drivers.

Totally understood, we'll confirm that ASAP. I wasn't able to catch Vadim today but I should be talking to him early next week. Keeping the NEEDINFO open for now. Thanks!
Comment 24 Yvugenfi@redhat.com 2016-08-19 10:26:41 UTC 
(In reply to Ladi Prosek from comment #23)
> (In reply to lijin from comment #22)
> > There is no one notify us about driver mapping changes.We just hope we are
> > testing the correct driver file.
> > 
> > So what we want to do is to confirm with all developers that all virtio-win
> > drivers mapping are changed according to windows kernel as following?
> > 
> > Wlh - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
> > Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
> > Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit ,
> > \ amd64 - 64bit)
> > Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)
> > 
> > If all developers confirmed the changes,qe will update the mapping table,and
> > test with the correct drivers.
> 
> Totally understood, we'll confirm that ASAP. I wasn't able to catch Vadim
> today but I should be talking to him early next week. Keeping the NEEDINFO
> open for now. Thanks!

Looks OK for NetKVM. But need to confirm that we provide INF2CAT with all OSes in Win8 configuration (should be done for all drivers).
Comment 25 Vadim Rozenfeld 2016-08-21 01:18:00 UTC 
(In reply to Ladi Prosek from comment #23)
> (In reply to lijin from comment #22)
> > There is no one notify us about driver mapping changes.We just hope we are
> > testing the correct driver file.
> > 
> > So what we want to do is to confirm with all developers that all virtio-win
> > drivers mapping are changed according to windows kernel as following?
> > 
> > Wlh - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
> > Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
> > Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit ,
> > \ amd64 - 64bit)
> > Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)
> > 
> > If all developers confirmed the changes,qe will update the mapping table,and
> > test with the correct drivers.
> 
> Totally understood, we'll confirm that ASAP. I wasn't able to catch Vadim
> today but I should be talking to him early next week. Keeping the NEEDINFO
> open for now. Thanks!

Sorry for delay.
Yes, we should follow the mapping mentioned above.
Best regards,
Vadim.
Comment 27 lijin 2016-08-21 08:01:47 UTC 
Ladi,Yan and Vadim.

Thank you for the confirm.

Now all drivers' mapping have been modified.
Comment 28 lijin 2016-08-24 02:35:42 UTC 
(In reply to Yan Vugenfirer from comment #24)
> (In reply to Ladi Prosek from comment #23)
> > (In reply to lijin from comment #22)
> > > There is no one notify us about driver mapping changes.We just hope we are
> > > testing the correct driver file.
> > > 
> > > So what we want to do is to confirm with all developers that all virtio-win
> > > drivers mapping are changed according to windows kernel as following?
> > > 
> > > Wlh - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
> > > Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
> > > Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit ,
> > > \ amd64 - 64bit)
> > > Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)
> > > 
> > > If all developers confirmed the changes,qe will update the mapping table,and
> > > test with the correct drivers.
> > 
> > Totally understood, we'll confirm that ASAP. I wasn't able to catch Vadim
> > today but I should be talking to him early next week. Keeping the NEEDINFO
> > open for now. Thanks!
> 
> Looks OK for NetKVM. But need to confirm that we provide INF2CAT with all
> OSes in Win8 configuration (should be done for all drivers).

Hi Yan,

There is no netkvm drvier in Wlh folder,I guess Vista folder should be used? 
Could you check if following mapping is correct?

Vista - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit , \ amd64 - 64bit)
Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)
Comment 29 Yvugenfi@redhat.com 2016-08-24 07:49:26 UTC 
(In reply to lijin from comment #28)
> (In reply to Yan Vugenfirer from comment #24)
> > (In reply to Ladi Prosek from comment #23)
> > > (In reply to lijin from comment #22)
> > > > There is no one notify us about driver mapping changes.We just hope we are
> > > > testing the correct driver file.
> > > > 
> > > > So what we want to do is to confirm with all developers that all virtio-win
> > > > drivers mapping are changed according to windows kernel as following?
> > > > 
> > > > Wlh - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
> > > > Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
> > > > Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit ,
> > > > \ amd64 - 64bit)
> > > > Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)
> > > > 
> > > > If all developers confirmed the changes,qe will update the mapping table,and
> > > > test with the correct drivers.
> > > 
> > > Totally understood, we'll confirm that ASAP. I wasn't able to catch Vadim
> > > today but I should be talking to him early next week. Keeping the NEEDINFO
> > > open for now. Thanks!
> > 
> > Looks OK for NetKVM. But need to confirm that we provide INF2CAT with all
> > OSes in Win8 configuration (should be done for all drivers).
> 
> Hi Yan,
> 
> There is no netkvm drvier in Wlh folder,I guess Vista folder should be used? 
> Could you check if following mapping is correct?
> 
> Vista - Windows 2008 (\x86 -32 bit , \amd64 - 64 bit)
> Win7 - Windows 7, Windows 2008 R2.  (\x86 - 32bit , \ amd64 - 64bit)
> Win8 - Windows 8 ,Windows 8.1 ,Windows 2012 ,Windows 2012R2  (\x86 - 32bit ,
> \ amd64 - 64bit)
> Win10 - Windows 10, Windows 2016  (\x86 - 32bit , \ amd64 - 64bit)

Hi,

XP driver should be used for Wlh.
Comment 30 lijin 2016-08-24 08:08:47 UTC 
netkvm driver version in XP folder is
32: DriverVer=08/11/2016,51.73.104.12600
64: DriverVer=08/11/2016,52.73.104.12600
the kernel version 51,52 are not the correct windows kernel version for win2008

netkvm driver version in Vista folder is:
DriverVer=08/11/2016,60.73.104.12600
Vista netkvm has the correct windows kernel version:60

And when we try to install netkvm driver on win2008 automatically,the default installed driver is in "Vista" folder.I guess it's Ladi's design.

Could you have a double check?
Comment 31 Yvugenfi@redhat.com 2016-08-24 11:28:23 UTC 
(In reply to lijin from comment #30)
> netkvm driver version in XP folder is
> 32: DriverVer=08/11/2016,51.73.104.12600
> 64: DriverVer=08/11/2016,52.73.104.12600
> the kernel version 51,52 are not the correct windows kernel version for
> win2008
> 
> netkvm driver version in Vista folder is:
> DriverVer=08/11/2016,60.73.104.12600
> Vista netkvm has the correct windows kernel version:60
> 
> And when we try to install netkvm driver on win2008 automatically,the
> default installed driver is in "Vista" folder.I guess it's Ladi's design.
> 
> Could you have a double check?

Just to clarify: WLH = Windows Server 2003.

And Windows Server 2008 and Vista kernel are the same on Windows.

Best regards,
Yan.
Comment 32 Yvugenfi@redhat.com 2016-08-24 11:29:56 UTC 
(In reply to Yan Vugenfirer from comment #31)
> (In reply to lijin from comment #30)
> > netkvm driver version in XP folder is
> > 32: DriverVer=08/11/2016,51.73.104.12600
> > 64: DriverVer=08/11/2016,52.73.104.12600
> > the kernel version 51,52 are not the correct windows kernel version for
> > win2008
> > 
> > netkvm driver version in Vista folder is:
> > DriverVer=08/11/2016,60.73.104.12600
> > Vista netkvm has the correct windows kernel version:60
> > 
> > And when we try to install netkvm driver on win2008 automatically,the
> > default installed driver is in "Vista" folder.I guess it's Ladi's design.
> > 
> > Could you have a double check?
> 
> Just to clarify: WLH = Windows Server 2003.
> 
> And Windows Server 2008 and Vista kernel are the same on Windows.
> 
> Best regards,
> Yan.

Sorry, my mistake. WLH is Windows 2008.

In any case for NetKVM Vista drivers should be installed on Windows Server 2008.
Comment 33 lijin 2016-09-02 07:32:35 UTC 
after confirmed with developers about the latest mapping and try on windows guest,correct driver can be loaded.

so change status to verified.
Comment 36 lijin 2016-09-06 06:51:58 UTC 
Hi Ladi and Yan,
 
We try to install netkvm driver on win2012R2 guest,it will load the netkvm driver in win8.1 folder,is this by design?
As we discussed before,win8.1 and win2012R2 should use drivers in win8 folder.
Comment 37 Yvugenfi@redhat.com 2016-09-06 08:27:03 UTC 
Win8.1 is Win2012R2. But we can use driver for from Win8 as well.
Comment 38 lijin 2016-09-07 01:42:39 UTC 
(In reply to Yan Vugenfirer from comment #37)
> Win8.1 is Win2012R2. But we can use driver for from Win8 as well.

Ok,we will use netkvm driver in win8.1 folder.
Comment 39 Ladi Prosek 2016-09-09 07:09:59 UTC 
Adding Yash to CC as this has packaging implications.
Comment 40 cobexer 2016-10-12 11:09:28 UTC 
Is it correct that this bug is not yet fixed in the oVirt 4 release?

And why is this tracked with RHEL 7 and not with oVirt / RHEV?
Comment 41 Michal Skrivanek 2016-10-31 14:04:25 UTC 
it's just a platform delivery, no other changes needed on oVirt/RHEV side (tested already with 4.0.4 as bug 1328181)
You will see the functionality once it is actually released in RHEL/CentOS
Comment 43 errata-xmlrpc 2016-11-04 08:53:15 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://rhn.redhat.com/errata/RHBA-2016-2609.html
Note You need to log in before you can comment on or make changes to this bug.