Description of problem: Import a VM with 2 ovirtmgmt/ovirtmgmt nics on RHV side. In UI VM import wizard, map the 2 networks as follows (attachment "network map setting screenshot"): nic1: Pod Networking Type: masquerade (Set by default and can't be changed) nic2: Name: ovn-kubernetes1 Type: bridge (Set by default and can't be changed) (attachment: "set network mapping" The VM import fails on: "The virtual machine could not be imported. VMCreationFailed: Error while creating virtual machine openshift-cnv/cirros-istein: admission webhook "virtualmachine-validator.kubevirt.io" denied the request: more than one interface is connected to a pod network in spec.template.spec.interfaces" (attachment: "vm-import-failure") Note that when setting the nics in a reverse order, make the VM import work, but with wrong networks. see bug 1850482. Version-Release number of selected component (if applicable): CNV-2.4 vm-import-operator: quay.io/kubevirt/vm-import-operator:v0.0.3 vm-import-controller: quay.io/kubevirt/vm-import-controller:v0.0.3 How reproducible: 100% Additional info: This was used to create the new network: $ oc apply -f second_network.yaml second_network.yaml: apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: ovn-kubernetes1 spec: config: '{ "cniVersion": "0.3.1", "type": "cnv-bridge", "bridge": "br1" }'
Created attachment 1698587 [details] set network mapping
Created attachment 1698588 [details] vm-import-failure
Created attachment 1698589 [details] VM yaml
Created attachment 1698591 [details] vm-import-controller.log
Please provide VM Import CR YAML int its state after the import.
Created attachment 1699022 [details] vm import CR yaml
In provided CR there is one mapped network: networkMappings: - source: id: 324d9357-4d0b-41c0-a28a-8aaae904b3ae type: pod so because of the defaults we attempt to use pod network for both interfaces. Can we check this from the api to be sure that it is only a UI issue?
Yes. I will check it. There might be something going on on the back-end as well.
We may want to make sure that we don't attempt to create VM with more than one pod network (default settings or not) by adding proper resource mapping validation.
Because both nics use the same vnic profile, both will be mapped to the same target; the UI set only one mapping in the VM import CR (to pod network) and as a result both nics were mapped to a pod network, which is an illegal kubevirt configuration. I can only speculate that UI holds the mapping of vnic profile ID to target in a map (which by itself has unique keys) and eventually the resource mapping in the import CR is created with whichever nic mapping was added to the map last. Please re-test with nics that use different vnic profiles.
Import VM with 2 nics on 2 different vnic profiles via UI: Map network1 to pod network2 to new network added VM import works fine. The VM created on CNV had these networks, which are exactly as set in the wizard: nic1: Pod Networking masquerade nic2: ovn-kubernetes1 bridge
The core problem of this and 1850482 bugs is the same - marking as a duplicate. *** This bug has been marked as a duplicate of bug 1850482 ***