Bug 1850509

Summary: [v2v][VM import from RHV to CNV] Import fail for setting nic1 to Pod and nic2 to a new network
Product: Container Native Virtualization (CNV) Reporter: Ilanit Stein <istein>
Component: V2VAssignee: Jakub Dzon <jdzon>
Status: CLOSED DUPLICATE QA Contact: Ilanit Stein <istein>
Severity: medium Docs Contact:
Priority: high    
Version: 2.4.0CC: cnv-qe-bugs, dagur, pelauter, pkliczew, pvauter
Target Milestone: ---   
Target Release: 2.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-30 11:17:43 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
set network mapping
none
vm-import-failure
none
VM yaml
none
vm-import-controller.log
none
vm import CR yaml none

Description Ilanit Stein 2020-06-24 12:30:06 UTC 
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"
    }'
Comment 1 Ilanit Stein 2020-06-24 12:30:45 UTC 
Created attachment 1698587 [details]
set network mapping
Comment 2 Ilanit Stein 2020-06-24 12:31:39 UTC 
Created attachment 1698588 [details]
vm-import-failure
Comment 3 Ilanit Stein 2020-06-24 12:32:25 UTC 
Created attachment 1698589 [details]
VM yaml
Comment 4 Ilanit Stein 2020-06-24 12:36:29 UTC 
Created attachment 1698591 [details]
vm-import-controller.log
Comment 5 Jakub Dzon 2020-06-24 12:41:04 UTC 
Please provide VM Import CR YAML int its state after the import.
Comment 6 Ilanit Stein 2020-06-28 10:47:59 UTC 
Created attachment 1699022 [details]
vm import CR yaml
Comment 7 Piotr Kliczewski 2020-06-29 06:56:39 UTC 
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?
Comment 8 Jakub Dzon 2020-06-29 07:06:18 UTC 
Yes. I will check it. There might be something going on on the back-end as well.
Comment 9 Jakub Dzon 2020-06-29 07:12:33 UTC 
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.
Comment 10 Jakub Dzon 2020-06-29 08:17:54 UTC 
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.
Comment 11 Ilanit Stein 2020-06-30 05:50:32 UTC 
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
Comment 12 Jakub Dzon 2020-06-30 11:17:43 UTC 
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 ***