This post is more than 5 years old
5 Practitioner
•
274.2K Posts
0
3553
will PER bit setting force Unmap\MAP from FA port for VMAX boxes ?
Guys ,
Customer needs to set PER bit for some volumes at VMAX running 5876 code.
This box was installed at 5874 code, so , volumes doesn't have PER bit by default.
It was upgraded to 5875 and 5876.
They realized that some W2K8 devices doesn't have PER bit and some have.
They informed that when trying to set this attribute , they are receiving a warning saying that volumes shoud be Unmapped from FA first.
Doing a binfile simulation it shows just the modification that we want :
| File_Name | Type_of_Change | proc_Name | Valid |
|---|---|---|---|
| impl_step_final.bin | Add_Dyn_Vol_Attr | DynDevAttrOnl | VALID |
I would like to know if both situations are really different , I mean , will software change UNMAP volumes from FA port and using binfile NOT ?
Need I handle it as a DIsruptive activity at host perspective ?
Thanks in advance,
Joelson
AranH1
2.2K Posts
0
June 10th, 2014 08:00
This is also in the Solutions Enabler Array Controls Product Guide.
Below is from page 49 of the latest 7.6 version:
SCSI3_persist_reserv (persistent group reservation) - In Enginuity 5874 and lower, this attribute is disabled by default. In Enginuity 5875 and higher, this attribute is enabled by default. When running Solutions Enabler V7.5 with Enginuity 5876 Q42012SR and higher, you can set or clear the SCSI-3 persistence attribute only if the device is unmapped.
EdwinVanMierlo
39 Posts
0
June 9th, 2014 00:00
"Need I handle it as a DIsruptive activity at host perspective ?"
Regardless, the Windows host must be rebooted after the change; so from a host perspective this is disruptive already
HTH,
Edwin.
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
June 9th, 2014 05:00
Edwin ,
Thanks for clarification.
My concern is about unmap/map operation.
Looks like that doing this using binfile It will not be unmapped/mapped while using software change it will.
Regards.
Joelson
sauravrohilla
859 Posts
0
June 9th, 2014 06:00
PER bit is an attribute so it can be enabled while the device online (mapped) through symcli. Do you have any document that shows otherwise?
EdwinVanMierlo
39 Posts
1
June 9th, 2014 06:00
I have never heard that "setting the PER bit with software" would cause an "unmap/map".... really never heard of it.
Where did you get this from ?
(please specify what software)
sauravrohilla
859 Posts
0
June 9th, 2014 06:00
but as Edwin said, host requires reboot post this change so its kind of disruptive.
regards,
Saurabh
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
June 10th, 2014 07:00
Guys,
Here is the output from customer when trying to set SCSI-3 PER bit :
bralk006:/home/b921316 ==>symconfigure -sid 023 -cmd "set dev 02DD attribute=SCSI3_persist_reserv;" prepare -v
Execute a symconfigure operation for symmetrix '000592600023' (y/ ) ? y
A Configuration Change operation is in progress. Please wait...
Establishing a configuration change session...............Established.
Error occurred while Defining change number 1:
The specified device must be unmapped before the configuration change can be applied.
Device 02DD generated the failure
Terminating the configuration change session..............Done.
The configuration change session has failed.
This caused the confusion.
Is there another way to set it by symcli ?
Regards.
Joelson
AranH1
2.2K Posts
0
June 10th, 2014 08:00
This is documented in the following KB article:
90580 : Symmetrix VMAX: Cannot set or clear the SCSI-3 persistence attribute (PER flag) at 5876.159.102 with Solutions Enabler 7.5.
https://support.emc.com/kb/90580
Resolution The product is working as designed. You can set or clear the SCSI-3 persistence attribute (PER flag), only if the device is unmapped
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
June 10th, 2014 08:00
Awesome guys…
Just to close this subject , and being 100% safe.
Doing this change using service processor script , via binfile ,will not cause unmap/map , right ?
Even though , to make effect server should be rebooted.
Regards.
Joelson
AranH1
2.2K Posts
1
June 10th, 2014 09:00
I just ran a few simulations and it looks like SymmWin blocks removing the attribute from a mapped device but is allowing adding the attribute from a device. I have asked the KB article owner for clarification since our documentation for SE blocks both actions.
AranH1
2.2K Posts
0
June 10th, 2014 09:00
I would assume that SymmWin would not be able to change that bit with the volume mapped. I am surpsied that the validation succeeded.
EdwinVanMierlo
39 Posts
0
June 11th, 2014 00:00
"
Below is from page 49 of the latest 7.6 version:
SCSI3_persist_reserv (persistent group reservation) - In Enginuity 5874 and lower, this attribute is disabled by default. In Enginuity 5875 and higher, this attribute is enabled by default. When running Solutions Enabler V7.5 with Enginuity 5876 Q42012SR and higher, you can set or clear the SCSI-3 persistence attribute only if the device is unmapped.
"
Well, that is a change I did not know about; so my previous response was incorrect.
Yes; it seems that you do need to unmap prior to changing this attribute.