Bug 1853911

Description of problem:
When adding secondary NIC to a VM, you cannot define the network name with a dot in it. This is in spite of k8s official documentation, which allegedly allows this (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names).
In addition - the message that is presented as a result of this failure is not clear and not relevant.


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


How reproducible:
Always


Steps to Reproduce:
1.
On a cluster with multi physical NIC on its node - create a bridge interface over one of the secondary interfaces, by applying the following policy:

cat << EOF | oc apply -f -
apiVersion: nmstate.io/v1alpha1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ens8-br-nncp
spec:
  desiredState:
    interfaces:
    - bridge:
        options:
          stp:
            enabled: false
        port:
        - name: ens8
      ipv6:
        enabled: false
      name: ens8-br
      state: up
      type: linux-bridge
  nodeSelector:
    kubernetes.io/hostname: host-172-16-0-34
EOF

Change the value of "kubernetes.io/hostname" to the hostname of a worker in your cluster.
Change the name of the bridge port (under interfaces[0].bridge.port.name) to the one a physcial secondary interface in the node. (It is also recommended to change the bridge name and NNCP name accordingly, but it's not mandatory).

2.
Create a NetworkAttachmentDefinition of the bridge you configured:
$ cat << EOF | oc apply -f -
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/ens8-br
  name: ens8-br-nad
  namespace: yoss-ns
spec:
  config: '{"cniVersion": "0.3.1", "name": "ens8-br", "plugins": [{"type":
    "cnv-bridge", "bridge": "ens8-br"}]}'
EOF

Change the bridge name according to the name you set in the previous step.

3.
Create a VM using the attached spec:
$ oc apply -f multus-vm-dot.yaml
(Change the nodeSelector value o the same node you used when configuring the NNCP).

4.
Start the VM:
$ virtctl start multus-vm

5.
Follow the progress of the VMI:
$ oc get vmi -w


Actual results:
<BUG>
1.
The VMI enters an infinite loop of scheduling, and can't get to Running state (in practice what happens is that on each iteration - a new VMI is created):
NAME        AGE   PHASE        IP    NODENAME
multus-vm   3s    Scheduling         
multus-vm   8s    Scheduled    10.128.2.129   host-172-16-0-34
multus-vm   9s    Scheduled    10.128.2.129   host-172-16-0-34
multus-vm   9s    Scheduled    10.128.2.129   host-172-16-0-34
...
multus-vm   10s   Scheduled    10.128.2.129   host-172-16-0-34
multus-vm   10s   Scheduled    10.128.2.129   host-172-16-0-34
multus-vm   11s   Failed       10.128.2.129   host-172-16-0-34
multus-vm   11s   Failed       10.128.2.129   host-172-16-0-34
multus-vm   11s   Failed       10.128.2.129   host-172-16-0-34
multus-vm   0s                                
multus-vm   0s                                
multus-vm   0s    Pending                     
multus-vm   0s    Scheduling                  
multus-vm   1s    Scheduling                  

2.
There is no clear message indicating that the failure is due to the name of network. When the VMI is gone and a new one is created, I see this output in the VMI describe:
$ oc describe vmi dhcp-server-vm
...
Events:
  Type     Reason            Age               From                                                         Message
  ----     ------            ----              ----                                                         -------
  Normal   SuccessfulCreate  10s               virtualmachine-controller                                    Created virtual machine pod virt-launcher-dhcp-server-vm-jt9s5
  Warning  SyncFailed        1s                virt-handler, master-2.cnvcl2.cnvqe.lab.eng.rdu2.redhat.com  unknown error encountered sending command SyncVMI: rpc error: code = Unavailable desc = transport is closing
  Warning  SyncFailed        1s (x11 over 1s)  virt-handler, master-2.cnvcl2.cnvqe.lab.eng.rdu2.redhat.com  failed to detect VMI pod: dial unix //pods/4701df26-d742-47da-85f4-b0770ec986f3/volumes/kubernetes.io~empty-dir/sockets/launcher-sock: connect: connection refused


Expected results:
1. According to https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - dot is a valid character in object names (and this configuration used to work properly on previous versions).
2. Upon such failure - there must be a clear message indicating that the failure is due to an invalid network name. It took a lot of debugging time from both QE and dev just to simplify the scenario and isolate it the case of bad network name.


Additional info:
1.
The problem is with the dot in the network nbame. Using the attached vm-multus.yaml works, when the difference between both spec if the dot vs. hyphen in the network name: $ diff multus-vm*.yaml
43c43
<             name: ens8.br
---
>             name: ens8-br
55c55
<         name: ens8.br
---
>         name: ens8-br

2.
This issue also occurs the *default* network name includes a dot (for example "d.efault").
So I assume the problem is not in multus, but elsewhere.