This post is more than 5 years old
30 Posts
0
2506
Changes to existing VMAX masking views: disruptive?
Hi everyone,
I'm going to need to perform the following two separate actions in the near future, and I'm curious whether there's even the slightest possibility that either of them might disrupt host I/O to storage:
1) On a VMAX2, I want to add two more FA ports to a port group that already has two, bringing it up to four.
2) On a VMAX3, I want to change a storage group's SLO policy.
The port group and the storage group in question are both members of masking views used by my production environment, so I'm very nervous that hot changes might disrupt the paths between storage and host. Does anyone have experience making these changes in active masking views and can testify that they're totally harmless? Can anyone link to documentation saying these actions have been tested and proved non-disruptive?
Thanks, everyone!
KW160
121 Posts
0
December 20th, 2015 17:00
The answer is that both #1 and #2 are online. Regarding #1, as long as you're not taking paths away, the existing paths will not be affected.
Regarding #2, this is an intended use case for SLOs. The system is designed for you to make those types of changes easily and online. For general documentation regarding Auto-Provisioning groups, I'd suggest the "Solutions Enabler 8.1 Array Management PDF".
tiro1
27 Posts
1
December 20th, 2015 05:00
Question 1 - Yes, you can add additional ports to a PG without causing any disruptions to the services. However, I prefer to make changes after hours and I would also involve platform team to run necessary path checks to ensure server has picked up the newly added paths.
I do not have hands-on experience on VMAX3.
EvgenyM1
51 Posts
1
December 23rd, 2015 04:00
Hello!
1- this is totally non-disruptive, if you are planning to add additional port you need to do that via:
symaccess -sid XXX -type port -name port_name add -dirport YY:Z, where YY:Z the full ID of port.
Don't forget to add zones between Initiators and newly added ports, otherwise LOGIN process will not occur.
Then you have to rescan BUS on host side to find out new paths to your device, that's all
2- you can change what even you want SLO for any storage group. Then based on new SLO the extents will be moved over between different type of drives within SRP (Storage resource pool)
thank you!
ben_brooks
30 Posts
0
December 23rd, 2015 11:00
Many thanks, everyone! You've answered the two questions I've asked.
But here's a plot twist: I've realized that after I add ports to the port group, I'll need to rename it. This is because all my port groups on the array are named after the ports they contain, e.g., 6-11H1_PG contains 6H:1 and 11H:1.
I assume renaming a port group is also known to be non-disruptive? Thanks again.
echolaughmk
522 Posts
1
December 23rd, 2015 18:00
Yup...renames are non-disruptive and can be done through the GUI or CLI.