Bug 1872564

Summary:	[Doc] Supported steps for correcting an environment setup with 'user_friendly_names' enabled on the hosts
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Marcus West <mwest>
Component:	Documentation	Assignee:	Eli Marcus <emarcus>
Status:	CLOSED CURRENTRELEASE	QA Contact:	rhev-docs <rhev-docs>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	4.3.11	CC:	aefrat, ctomasko, ddacosta, emarcus, imomin, lsurette, mavital, mhicks, mkalinin, pelauter, sfishbai, srevivo
Target Milestone:	ovirt-4.4.10	Keywords:	Documentation, ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-01-25 15:21:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Docs	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marcus West 2020-08-26 05:49:21 UTC

## Description of problem:

Supported steps for correcting an environment setup with 'user_friendly_names' enabled on the hosts (multipath, FC storage)

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

RHVM 4.3

## How reproducible:

Always

## Steps to Reproduce:
1. Set up RHV environment with 'user_friendly_names' enabled
2. Realize that it's not supported, want to correct it without having to migrate everything to a new SD

## Actual results:


## Expected results:


## Additional info:

In this case, it's preferable to have a small outage while we take storage down, instead of the prolonged activity of live storage migrating every VM through shuffled Storage Domains.

Comment 2 Eyal Shenitzky 2020-08-31 14:58:30 UTC

Amit, can you please confirm that the steps in comment #1 are the right steps to rollback from the use of user_friendly_names

Comment 4 Amit Bawer 2020-09-01 07:41:03 UTC

(In reply to Eyal Shenitzky from comment #2)
> Amit, can you please confirm that the steps in comment #1 are the right
> steps to rollback from the use of user_friendly_names

Not clear to me why it was needed to update the LUN UUIDs in the metadata 
as a result.  the reason that vdsm deployment sets "user_friendly_names" to "no"
it to have consistent /dev/mapper/{LUN UUID} naming for iscsi devices
while being shared between hosts as there is no guarantee that multipath
will use the same friendly mpath{x} alias for the same LUN from different hosts.

The LUN UUID is a fixed unique ID for the LUN while /dev/mapper/mpath{x} is
a multipath friendly device alias on the host that i don't recall as
persisted to the metadata itself (which keeps md pv UUIDs same as the LUN UUID)
but only resolved during runtime.

Comment 5 Amit Bawer 2020-09-01 07:53:25 UTC

(In reply to Amit Bawer from comment #4)
> (In reply to Eyal Shenitzky from comment #2)
> > Amit, can you please confirm that the steps in comment #1 are the right
> > steps to rollback from the use of user_friendly_names
> 
> Not clear to me why it was needed to update the LUN UUIDs in the metadata 
> as a result.  the reason that vdsm deployment sets "user_friendly_names" to
> "no"
> it to have consistent /dev/mapper/{LUN UUID} naming for iscsi devices
> while being shared between hosts as there is no guarantee that multipath
> will use the same friendly mpath{x} alias for the same LUN from different
> hosts.
> 
> The LUN UUID is a fixed unique ID for the LUN while /dev/mapper/mpath{x} is
> a multipath friendly device alias on the host that i don't recall as
> persisted to the metadata itself (which keeps md pv UUIDs same as the LUN
> UUID)
> but only resolved during runtime.

Wrong comment, i can see why it might have need to be changed.
in vg tags it can keep the mpath name for the MDT_PV0=pv:mpathj&44&uuid as friendly name
even when friendly_name is set back to "no" and multipath is reconfigured.

What confused me is that in comment #1 it had to be changed from LUN ID x to LUN ID y
and not from mpath{n} to LUN ID. was the VG there created after setting the friendly names to "no" ?

Comment 6 Marcus West 2020-09-02 01:47:27 UTC

Hi Amit,

Apologies for the confusing in my example.  I was trying to reproduce this by changing the WWID, rather than go from an alias back to the WWID.  I did this to avoid setting up friendly_name storage in the first place, but in hindsight i should have just done it as it would have made things easier...

Comment 12 Marina Kalinin 2022-01-22 00:04:52 UTC

Thanks Eli and all who helped updating it. I see Gordon updated the KCS last: https://access.redhat.com/solutions/4758231.
Sounds like this makes this BZ complete and we should close it.