I have a volume that contains one lun, and I need to rename the lun & then the volume, or vise versa....
It looks like I can use the "lun move" command wihtout disruption (I am not running snap mirror) ? Is this correct, But it also has to be done on the same volume. I can't move a Lun to another volume non dispruptilvy to the host.. or can I????
After I get the lun renamed, I want to rename the volume.
I was alwasy under the impression that this would cause a disruption for the host, because of the path to the lun via the volume. However, I then came across some info that because the lun is mapped by serial number, I can rename the volume and/or lun without any disruption tot he host.
So basically what is the impact on renaming a lun and/or volume?
Your understanding is correct. You are able to use 'lun move' to change the LUN path. The LUN is mapped to the igroup via the LUN serial number, not the path name like an NFS mount or CIFS share. We helped one of our largest FC SAN customers do this procdid this procedure NON Disruptively in their environment several years ago. Their scenario was that they were not using qtrees and they wanted to start using SnapVault. The pro's and con's for many approaches were weighed, and then finally they decided to add a token qtree to each volume, and use 'lun move' to move the LUN into the newly created qtree. Non-Disruptively. They did this across several thousand LUNs in their environment. While your use case is sligtly different, I see it as being very close to what performed. 'Lun move' should work well for you.
Ideally, however, you should aldo prove this to yourself if possible. Hopefully you or the custoemer has access to a lab setup so you can run through trial scenarios prior to attempting in their production environment.
Hope this helps.
I will say "it should work". The scenario we performed was slightly different. In their scenario was something like this:
Also, they HAVE renamed volumes in the past with active LUNs in them with no disruption. That however was a different use case. Their volume naming convention has the server hostname as part of the volume name, and the 'vol rename' was used to correct fat fingered mistakes after the fact.
Hope this helps,