Bug 1884975 - [v2v][VMware to CNV VM import API] Storage Mapping: Using VMware storage name cause a crash
Summary: [v2v][VMware to CNV VM import API] Storage Mapping: Using VMware storage name...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: V2V
Version: 2.5.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 2.5.0
Assignee: Sam Lucidi
QA Contact: Md Nadeem
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-04 08:50 UTC by Ilanit Stein
Modified: 2020-11-17 13:25 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-17 13:24:56 UTC
Target Upstream Version:


Attachments (Terms of Use)
vm import resource yaml (2.41 KB, text/plain)
2020-10-04 08:50 UTC, Ilanit Stein
no flags Details
vm import controller log (9.75 KB, text/plain)
2020-10-04 08:51 UTC, Ilanit Stein
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:5127 0 None None None 2020-11-17 13:25:33 UTC

Description Ilanit Stein 2020-10-04 08:50:01 UTC
Description of problem:
VM import from VMware to RHV via api, using "name" for the source storage,
causes a crash:
VM import remain in 5%. VM import resource report validation completed.
VM import controller log report:
"panic: runtime error: invalid memory address or nil pointer dereference [recovered]
        panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1ebe93b]

goroutine 1394 [running]:
k8s.io/apimachinery/pkg/util/runtime.HandleCrash(0x0, 0x0, 0x0)" 

Version-Release number of selected component (if applicable):
CNV-2.5

Additional info:
Source (VMware) storage name was used due to this doc bug:
Bug 1884970 - [v2v][Doc][VMware to CNV VM import API] Storage Mapping: Source storage name should change to storage id

Additional info - How it was tested:
Secret:
------
cat <<EOF | oc create -f -
---
apiVersion: v1
kind: Secret
metadata:
 name: vmw-secret
type: Opaque
stringData:
 vmware: |-
   # API URL of the vCenter or ESXi host
   apiUrl: "https://<Vcenter IP address>/sdk"
   # Username provided in the format of username@domain.
   username: <username>
   password: <password>
   # The certificate thumbprint of the vCenter or ESXi host, in colon-separated hexidecimal octets.
   thumbprint: 31:14:..
EOF

External mapping
----------------

cat <<EOF | oc create -f -
apiVersion: v2v.kubevirt.io/v1beta1
kind: ResourceMapping
metadata:
 name: example-vmware-resourcemappings
 namespace: default
spec:
  vmware:
    networkMappings:
    - source:
        name: VM Network # map network name to network attachment definition
      target: 
        name: pod
      type: pod
    storageMappings:
    - source:
        name: <VMware datastore name>   <======== Here use a name instead of ID
      target: 
        name: nfs
EOF

VM import create
----------------
cat <<EOF | oc create -f -
apiVersion: v2v.kubevirt.io/v1beta1
kind: VirtualMachineImport
metadata:
  name: vmware-import-1
  namespace: default
spec:
  providerCredentialsSecret:
    name: vmw-secret
    namespace: default # optional, if not specified, use CR's namespace
  resourceMapping:
    name: example-vmware-resourcemappings
    namespace: default
  targetVmName: vmw-import
  startVm: false
  source:
    vmware:
      vm:
        id: 42037aff-4d6f-cf89-7979-e98cbc406c0e
EOF

Comment 1 Ilanit Stein 2020-10-04 08:50:53 UTC
Created attachment 1718741 [details]
vm import resource yaml

Comment 2 Ilanit Stein 2020-10-04 08:51:32 UTC
Created attachment 1718742 [details]
vm import controller log

Comment 3 Sam Lucidi 2020-10-05 20:47:32 UTC
https://github.com/kubevirt/vm-import-operator/pull/410 fixes the doc bug and allows Datastores to be mapped by Name as well.

Comment 4 Md Nadeem 2020-10-23 16:09:14 UTC
verified on CNV version: 2.5.0-234

VM import works with both storage id or storage name

Comment 7 errata-xmlrpc 2020-11-17 13:24:56 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 (OpenShift Virtualization 2.5.0 Images), 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/RHEA-2020:5127


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