Bug 2068143

Summary:	[cnv 4.8] No "permittedHostDevices" section in HCO CR, allows any hostdevice in the VM spec.
Product:	Container Native Virtualization (CNV)	Reporter:	Kedar Bidarkar <kbidarka>
Component:	Virtualization	Assignee:	sgott
Status:	CLOSED ERRATA	QA Contact:	Kedar Bidarkar <kbidarka>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.8.0	CC:	cnv-qe-bugs, vsibirsk
Target Milestone:	---
Target Release:	4.8.6
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	virt-operator-container-v4.8.6-3 hco-bundle-registry-container-v4.8.6-21	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-31 14:33:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kedar Bidarkar 2022-03-24 14:31:43 UTC

This bug was initially created as a copy of Bug #1983079

I am copying this bug because: 



Description of problem:

1) Empty or No "permittedHostDevices" section in HCO CR, allows any hostdevice in the VM spec.

2) It appears that the validation of the vm specs hostdevice is done, only after we add the first entry under "permittedHostDevices" section in HCO CR.

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

How reproducible:
Without adding any entry about "permittedHostDevices" in HCO CR, 
create a VMI spec with any random hostdevices name.

Steps to Reproduce:
1. Create a VM with hostdevice, with no "permittedHostDevices" section in HCO CR
2. Creation of the VM witht he hostdevice is allowed.
3. ( Ofcourse the VM would then be in a PENDING state )

Actual results:

1) Empty or No "permittedHostDevices" section in HCO CR, should deny all hostdevices, by default.

2) It appears that the validation of the vm specs hostdevice is done, only after we add the first entry under "permittedHostDevices" section in HCO CR.

Expected results:

Even if the  "permittedHostDevices" section is missing from HCO CR
The VM creation with "Any" HostDevice should be denied with the below message.

Message: "admission webhook .* denied the request: HostDevice {GPU_DEVICE_NAME} is not permitted .*"

Additional info:

Comment 1 vsibirsk 2022-05-23 10:41:31 UTC

Verified with:
hco-operator v4.8.6-3
virt-operator v4.8.6-4


$ oc get kubevirt kubevirt-kubevirt-hyperconverged -n openshift-cnv -o yaml | grep -i permittedHostDevices
$ 
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o yaml | grep -i permittedHostDevices
$ 

2) Created a VM with the below spec in it.
Spec:
  Domain:
    Cpu:
      Cores:    1
      Model:    host-model
      Sockets:  1
      Threads:  1
    Devices:
      Disks:
        Disk:
          Bus:  virtio
        Name:   containerdisk
        Disk:
          Bus:  virtio
        Name:   cloudinitdisk
      Host Devices:
        Device Name:  nvidia.com/TU104GL_Tesla_T4
        Name:         hostdevice


3) Started the VM, VMI is in "scheduling" state, with the below msg.
Status:
  Active Pods:
    0c051075-a34f-4661-8289-1e5087f16319:  
  Conditions:
    Last Probe Time:       <nil>
    Last Transition Time:  2022-05-23T10:35:22Z
    Message:               0/6 nodes are available: 1 Insufficient nvidia.com/TU104GL_Tesla_T4, 2 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.
    Reason:                Unschedulable
    Status:                False
    Type:                  PodScheduled
  Guest OS Info:
  Phase:      Scheduling
  Qos Class:  Burstable

Comment 7 errata-xmlrpc 2022-05-31 14:33:58 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 (OpenShift Virtualization 4.8.6 Images), 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/RHEA-2022:4843