Bug 1841065

Summary: [v2v] RHV to CNV: VM import fail on network mapping validation
Product: Container Native Virtualization (CNV) Reporter: Ilanit Stein <istein>
Component: V2VAssignee: Piotr Kliczewski <pkliczew>
Status: CLOSED ERRATA QA Contact: Ilanit Stein <istein>
Severity: high Docs Contact:
Priority: high    
Version: 2.4.0CC: cnv-qe-bugs, fkrepins, ncredi
Target Milestone: ---   
Target Release: 2.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kubevirt-vmware:v2.0.0-4 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-28 19:10:09 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:
Bug Depends On: 1841107    
Bug Blocks:    

Description Ilanit Stein 2020-05-28 09:15:14 UTC
Component: 
VM Import operator

Description of problem:
UI VM Import from RHV to CNV of a RHEL-8 VM, with a single nic, fails on: 

Error "Required value" for field "spec.source.ovirt.mappings.networkMappings.target"   

Piotr Kliczewski:
"
I checked vm-import-controller logs by running:
oc logs vm-import-controller-6c64995476-plljx -n openshift-cnv
and it seems there were no vmimports created so no import operations happened.


I ran the import from the UI and I was able to reproduce. I chose a vm and went with defaults without any changes.
Here is the yaml:

kind: VirtualMachineImport
apiVersion: v2v.kubevirt.io/v1alpha1
metadata:
  generateName: vm-import-test-
  namespace: default
spec:
  startVm: false
  source:
    ovirt:
      vm:
        id: 2c6aaddc-235a-4b4c-85c5-e5a552ea39c1
      mappings:
        networkMappings:
          - source:
              id: 324d9357-4d0b-41c0-a28a-8aaae904b3ae
            type: pod
        diskMappings:
          - source:
              id: badb5320-5f1a-45ec-b844-1714d87de899
            target:
              name: null
  targetVmName: test
  providerCredentialsSecret:
    name: admin-rhev-blue-01-rdu2-scalel-5kxgk
    namespace: default

The failure message is:

Error "Invalid value: "null": spec.source.ovirt.mappings.diskMappings.target.name in body must be of type string: "null"" for field "spec.source.ovirt.mappings.diskMappings.target.name".

At this stage there is no interaction with the backend.


The above yaml is rejected by the api. 
I tried to create it using cli and I get:

* spec.source.ovirt.mappings.diskMappings.target.name: Invalid value: "null": spec.source.ovirt.mappings.diskMappings.target.name in body must be of type string: "null"
* spec.source.ovirt.mappings.networkMappings.target: Required value
"

Filip Krepinsky:
In case you did not change anything and the VM has one network, then pod network was selected by default and target was set to undefined. Having a target doesn't make sense for pod networks so this is a bug on vm-import-operator side IMO.

There must be a problem with the resource validation as I don't see a problem with the generated YAML (please double check).
pod network should not require a target  
        diskMappings:
          - source:
              id: badb5320-5f1a-45ec-b844-1714d87de899
            target:
              name: null

null should indicate that the default storage class should be used (which is standard in this case) or no class. When I replace it with standard the error disappears.

Version-Release number of selected component (if applicable):
OCP-4.5
CNV-2.3
RHV-4.3

Comment 1 Piotr Kliczewski 2020-05-28 09:26:29 UTC
It seems like we have regression after working on csv generator. Let's align with older vmimport CRD.

Comment 2 Piotr Kliczewski 2020-05-28 11:34:18 UTC
Apparently the CRD is correct. It is a mystery how it worked before.

Comment 3 Ilanit Stein 2020-06-09 06:37:37 UTC
Verified on:
v2v-conversion-image: quay.io/kubevirt/kubevirt-vmware:v2.0.0-4
vm-import-operator v0.0.3

Managed to VM import from RHV to CNV using default mapping, which have failed on previous versions.

Comment 6 errata-xmlrpc 2020-07-28 19:10:09 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, 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/RHSA-2020:3194