Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1874074

Summary: [CNV] Windows 2019 Default Template Not Defaulting to Proper NIC/Storage Driver
Product: OpenShift Container Platform Reporter: Benjamin Schmaus <bschmaus>
Component: Console Kubevirt PluginAssignee: Yaacov Zamir <yzamir>
Status: CLOSED ERRATA QA Contact: Guohua Ouyang <gouyang>
Severity: low Docs Contact:
Priority: high    
Version: 4.5CC: aos-bugs, cnv-qe-bugs, fdeutsch, fkrepins, gouyang, oyahud, tjelinek, ycui, yzamir
Target Milestone: ---   
Target Release: 4.7.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-24 15:16:47 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
win 2019 flow with sata and e1000 working none

Description Benjamin Schmaus 2020-08-31 13:47:54 UTC
Description of problem: Customer used a Windows 2019 template via the wizard and the NIC was defined as virtio by default which caused VM to not have networking on bootup.


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

How reproducible:
100%

Steps to Reproduce:
1.Install CNV 2.3
2.Create a Windows 2019 VM via wizard
3.Boot VM
4.Via console go into Windows 2019 VM and device manager and nic will have a "?" on it since no driver available.

Actual results:
Windows 2019 template creates a NIC with virtio driver

Expected results:
By default WIndows 2019 should be created wit a SATA disk and e1000e NIC

Additional info:

Comment 1 Fabian Deutsch 2020-08-31 14:01:38 UTC
Let's understand if this is a UI or template issue.

Comment 3 Omer Yahud 2020-09-01 09:04:13 UTC
I can see e1000e is already used in our templates: https://github.com/kubevirt/common-templates/blob/master/templates/windows.tpl.yaml#L125
Maybe an older version of the template was used? can you please provide the VM spec?

Comment 4 Benjamin Schmaus 2020-09-04 15:40:45 UTC
So I can still see this behavior in a 4.5.7 OCP cluster with CNV 2.4.

If I go to the UI->Create VM Wizard->Select Windows 2019 as OS Type->Networking screen still provides me a nic-0 with VirtIO.

Comment 5 Fabian Deutsch 2020-09-04 19:50:02 UTC
Tomas, can this be a modification of the UI?

Comment 6 Tomas Jelinek 2020-09-05 16:58:50 UTC
Indeed it is a bug in the UI, taking.

@Benjamin: when you pick a windows OS, you will get the windows guest tools automatically attached so you should find the drivers inside of your VM on a CD so you should be able to install them. Does this work for you?

Comment 7 Benjamin Schmaus 2020-09-09 15:42:20 UTC
Both the customer and myself through testing did see the guest tools mounted.  However the customer actually preferred my workaround of editing the NIC driver before deploying the VM where we set it to rtl8139 which allowed Windows to come up without any additional guest tool installs.   Why can't the UI have e1000 as the default when Windows is selected as the OS?

Comment 8 Filip Krepinsky 2020-09-10 12:14:07 UTC
As what is UI concerned. This is either about 

1. Adding a new feature and accepting nics/disks from common templates. It is currently not implemented.

or

2. Adding interface model validations into common templates and specifying the right interface model as recommended (justWarning attribute). The UI could then act upon this.


Nevertheless, either of these is not a simple bug fix.

Comment 9 Tomas Jelinek 2020-09-11 09:36:42 UTC
I would go with option 1 - similarly to https://github.com/openshift/console/pull/6543

Comment 10 Filip Krepinsky 2020-09-11 14:03:14 UTC
ok, so what are going to do in this bug fix? 

Copy all networks from common templates to the final VM/Template? And disable the current automatic pod network creation by the UI? Are we going to also include disks?

Comment 11 Tomas Jelinek 2020-09-11 14:14:30 UTC
(In reply to Filip Krepinsky from comment #10)
> ok, so what are going to do in this bug fix? 
> 
> Copy all networks from common templates to the final VM/Template?

yes, we can not ignore them

 
> And disable the current automatic pod network creation by the UI? Are we going
> to also include disks?

That is less important now since there are none. But in general we should. But as part of this fix Id worry about the templates.

Comment 12 Tomas Jelinek 2020-09-22 08:51:20 UTC
severity is low, moving out of blocker list

Comment 13 Yaacov Zamir 2021-01-11 08:38:46 UTC
works for me on current master, moving to modified

Comment 14 Yaacov Zamir 2021-01-11 08:39:47 UTC
Created attachment 1746183 [details]
win 2019 flow with sata and e1000 working

Comment 18 errata-xmlrpc 2021-02-24 15:16:47 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 (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), 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/RHSA-2020:5633