Bug 1841065 - [v2v] RHV to CNV: VM import fail on network mapping validation
Summary: [v2v] RHV to CNV: VM import fail on network mapping validation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: V2V
Version: 2.4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 2.4.0
Assignee: Piotr Kliczewski
QA Contact: Ilanit Stein
URL:
Whiteboard:
Depends On: 1841107
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-28 09:15 UTC by Ilanit Stein
Modified: 2020-07-28 19:10 UTC (History)
3 users (show)

Fixed In Version: kubevirt-vmware:v2.0.0-4
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-28 19:10:09 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt vm-import-operator pull 261 0 None closed Reduce restrictions on targer in mappings 2020-08-05 13:13:06 UTC
Red Hat Product Errata RHSA-2020:3194 0 None None None 2020-07-28 19:10:26 UTC

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


Note You need to log in before you can comment on or make changes to this bug.