Bug 1841065
| Summary: | [v2v] RHV to CNV: VM import fail on network mapping validation | ||
|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | Ilanit Stein <istein> |
| Component: | V2V | Assignee: | Piotr Kliczewski <pkliczew> |
| Status: | CLOSED ERRATA | QA Contact: | Ilanit Stein <istein> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 2.4.0 | CC: | 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: | |
| Embargoed: | |||
| Bug Depends On: | 1841107 | ||
| Bug Blocks: | |||
It seems like we have regression after working on csv generator. Let's align with older vmimport CRD. Apparently the CRD is correct. It is a mystery how it worked before. 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. 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 |
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