Bug 1948965 - Destination storage in migration plan storage mapping is ignored. Default storage is picked instead.
Summary: Destination storage in migration plan storage mapping is ignored. Default sto...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Migration Toolkit for Virtualization
Classification: Red Hat
Component: General
Version: 2.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 2.0.0
Assignee: Jeff Ortel
QA Contact: Ilanit Stein
Avital Pinnick
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-13 07:22 UTC by Ilanit Stein
Modified: 2021-06-10 17:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-10 17:11:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
plan yaml (13.50 KB, text/plain)
2021-04-13 13:11 UTC, Ilanit Stein
no flags Details
storage mapping yaml (2.08 KB, text/plain)
2021-04-13 13:12 UTC, Ilanit Stein
no flags Details
Network mapping yaml (1.99 KB, text/plain)
2021-04-13 13:12 UTC, Ilanit Stein
no flags Details
dv yaml (14.20 KB, text/plain)
2021-04-13 13:14 UTC, Ilanit Stein
no flags Details
cdi deployment log (11.74 KB, text/plain)
2021-04-13 13:15 UTC, Ilanit Stein
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2021:2381 0 None None None 2021-06-10 17:11:57 UTC

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


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