Bug 1948965

Summary: Destination storage in migration plan storage mapping is ignored. Default storage is picked instead.
Product: Migration Toolkit for Virtualization Reporter: Ilanit Stein <istein>
Component: GeneralAssignee: Jeff Ortel <jortel>
Status: CLOSED ERRATA QA Contact: Ilanit Stein <istein>
Severity: high Docs Contact: Avital Pinnick <apinnick>
Priority: high    
Version: 2.0.0CC: amastbau, apinnick, dagur, fdupont, istein, nachandr
Target Milestone: ---Keywords: Regression
Target Release: 2.0.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: 2021-06-10 17:11:46 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
plan yaml
none
storage mapping yaml
none
Network mapping yaml
none
dv yaml
none
cdi deployment log none

Description Ilanit Stein 2021-04-13 07:22:18 UTC
Description of problem:
On a OCP cluster with storage "standard" - "kubernetes.io/cinder" set as the default storage, creating a migration plan, for a single RHEL7 VM, with storage mapping that maps to a non default storage, "nfs".
After starting the plan, there is a trial to bound PVC to "standard" storage, and not to "nfs" as expected. the VM import remains "pending" forever.

If changing the default storage to nfs, for a migration plan with destination storage nfs, the PVC is bound to nfs, and the migration plan ends successfully  

Version-Release number of selected component (if applicable):
MTV 2.0.0-15
CNV-2.6.0 (Currently not able to use CNV-2.6.1 since of PSI down issue)

Comment 1 Fabien Dupont 2021-04-13 07:54:03 UTC
How is the mapping created? API or UI?
Can you please share the YAML (oc get -o yaml) for the plan and mappings?

Comment 2 Ilanit Stein 2021-04-13 13:10:31 UTC
The mappings were created from UI.

Comment 3 Ilanit Stein 2021-04-13 13:11:37 UTC
Created attachment 1771616 [details]
plan yaml

Comment 4 Ilanit Stein 2021-04-13 13:12:07 UTC
Created attachment 1771617 [details]
storage mapping yaml

Comment 5 Ilanit Stein 2021-04-13 13:12:46 UTC
Created attachment 1771618 [details]
Network mapping yaml

Comment 6 Ilanit Stein 2021-04-13 13:14:22 UTC
Created attachment 1771621 [details]
dv yaml

Comment 7 Ilanit Stein 2021-04-13 13:15:05 UTC
Created attachment 1771622 [details]
cdi deployment log

Comment 9 Fabien Dupont 2021-04-16 07:41:56 UTC
The fix should be part of build 2.0.0-17 / iib:66911.

Comment 11 Fabien Dupont 2021-04-16 20:04:35 UTC
Apparently not in build 2.0.0-17. Moving back to MODIFIED.

Comment 12 Fabien Dupont 2021-04-19 10:16:27 UTC
The fix should be part of MTV 2.0.0-18 / iib:68063.

Comment 13 Amos Mastbaum 2021-04-26 11:43:03 UTC
verified MTV 2.0.0-20 (iib:69034)

Comment 16 errata-xmlrpc 2021-06-10 17:11:46 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 (MTV 2.0.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-2021:2381