Should we be targeting this bug for 4.10.7 and not 4.10.6?

Just so as to avoid regression when someone upgrading CNV from 4.10.6 to 4.11.0.

4.10.6 ---> PSA enabled
4.11.0 ---> no PSA support
4.11.1 ---> PSA enabled

We would have 4.10.7 release again, before 4.12.0 release.

This shouldn't cause an issue with the upgrade path. For our purposes, "PSA enabled" effectively means we're adding correct labels to resources. Thus moving to a cluster version that's not aware and then back to one that is will not cause any sort of issue.

Verified on  v4.10.6-29

Vm can be successfully started 

[akrgupta@fedora ~]$ oc get vm
NAME            AGE   STATUS         READY
vm-rhel84-ocs   34s   Provisioning   False
[akrgupta@fedora ~]$ virtctl start vm-rhel84-ocs
VM vm-rhel84-ocs was scheduled to start
[akrgupta@fedora ~]$ oc get vm
NAME            AGE   STATUS    READY
vm-rhel84-ocs   12m   Running   True
[akrgupta@fedora ~]$ oc get vmi
NAME            AGE     PHASE     IP            NODENAME                            READY
vm-rhel84-ocs   6m44s   Running   10.128.2.85   virt-akr-410-z96nw-worker-0-l8mq6   True
[akrgupta@fedora ~]$ oc get pod
NAME                                READY   STATUS    RESTARTS   AGE
virt-launcher-vm-rhel84-ocs-6gv72   1/1     Running   0          6m49s
[akrgupta@fedora ~]$ virtctl migrate vm-rhel84-ocs
VM vm-rhel84-ocs was scheduled to migrate
[akrgupta@fedora ~]$ oc get vmi
NAME            AGE     PHASE     IP            NODENAME                            READY
vm-rhel84-ocs   8m55s   Running   10.131.0.57   virt-akr-410-z96nw-worker-0-hckzd   True

1) created new namespace - it has default labels:
[akrgupta@fedora auth]$ oc describe ns namsespace-example
Name:         namsespace-example
Labels:       kubernetes.io/metadata.name=namsespace-example

2) Created and started VM in this namespace - labels updated:
[akrgupta@fedora ~]$ oc get vm
NAME            AGE     STATUS    READY
vm-rhel86-ocs   8m16s   Running   True
[akrgupta@fedora ~]$ oc describe ns namsespace-example
Name:         namsespace-example
Labels:       kubernetes.io/metadata.name=namsespace-example
              pod-security.kubernetes.io/enforce=privileged
              security.openshift.io/scc.podSecurityLabelSync=false

3) Removed VM - labels still the same (not reverted back):
[akrgupta@fedora ~]$ oc delete vm vm-rhel86-ocs
virtualmachine.kubevirt.io "vm-rhel86-ocs" deleted
[akrgupta@fedora ~]$ oc describe ns namsespace-example
Name:         namsespace-example
Labels:       kubernetes.io/metadata.name=namsespace-example
              pod-security.kubernetes.io/enforce=privileged
              security.openshift.io/scc.podSecurityLabelSync=false

PSA feature gate is present
[akrgupta@fedora ~]$ oc get kv -n openshift-cnv kubevirt-kubevirt-hyperconverged -o json | grep -A 15 "featureGates"
                "featureGates": [
                    "DataVolumes",
                    "SRIOV",
                    "CPUManager",
                    "CPUNodeDiscovery",
                    "Snapshot",
                    "HotplugVolumes",
                    "ExpandDisks",
                    "GPU",
                    "HostDevices",
                    "DownwardMetrics",
                    "NUMA",
                    "LiveMigration",
                    "PSA",
                    "WithHostModelCPU",
                    "HypervStrictCheck",

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.10.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:7179