## 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.
Amit, can you please confirm that the steps in comment #1 are the right steps to rollback from the use of user_friendly_names
(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.
(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" ?
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...
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.