HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Application Integration
Showing results for 
Search instead for 
Did you mean: 

Renaming Nimble Volumes for SQL Connectivity

Go to solution
Occasional Visitor

Renaming Nimble Volumes for SQL Connectivity

We have several nimble volumes that we would like to change the name of.  These volumes contain SQL DBs and Logs and are being passed as RDM's through our VMware hosts to our virtual SQL servers. 

As far as I know, the nimble volume name is included in the iqn for the volume/LUN.  Can we rename the volume live without impacting the volume or would we have to disconnect from the LUN (after turning of the SQL services of course), rename the volume then reconnect to the LUNs?



Re: Renaming Nimble Volumes for SQL Connectivity

The short answer is "No, it WILL impact" the volume...but I love to break things so I tried it out in a test environment.

Since these are RDMs, the iSCSI connectivity is via ESX, not directly from the Windows guest.  While *technically* the volume rename would not be immediately disruptive, it will ultimately lead to dropping paths to the volumes from the ESX host.  I tested it in my lab as so:

I created a volume, attached it to a test instance of SQL as an RDM, wrote some files to it.  All worked as expected.


I renamed the target in the Nimble array.  RDM remained mounted to the guest, so far non disruptive.

I recscanned the iSCSI initiator and saw the volume go to "lost communication" status.  However, the guest CONTINUED to see the RDM volume - writing was still possible to the volume at this point.

I then tried re-booting the guest - and the VM threw up all over itself.  It threw errors while shutting down and would not reboot until I deleted the RDM and then added it back in - this time as a VMFS as the RDM was already established.  So it WAS recoverable but it sure as hell would be disruptive to attempt this in production.

As I wanted to respond to you quickly, the short answer is that it will work for a while but you are going to have problems if you remain in that state.  There is one last test you have me wondering about - Now that that guest is back on line, I am going to rename the volume again and see if it drops on it's own - my guess is that it will drop within 24 hours as the initiator polls for active targets.

I'll report back once I confirm that.

Frequent Advisor

Re: Renaming Nimble Volumes for SQL Connectivity

These are my notes from the steps I followed to rename a volume Randy.  Vince in Nimble support was really helpful with this.

  1. Run on each host per KB59:
    • for i in `esxcli storage nmp device list | awk '/Nimble iSCSI Disk/{print $7}' | sed -e 's/(//' -e 's/)//'`; do esxcli storage nmp psp roundrobin deviceconfig set --type "iops" --iops=0 --device=$i; done
  2. Ref kb54 to remove volume
  3. shut down vms on vmfs vol to be renamed
  4. right click datastore, unmount
  5. go to iscsi init properties (under hosts) - static disc - remove vol paths - say no to re-scan
  6. go to nimble gui and take vol offline
  7. rescan all from esx
  8. then you will no longer see volume
  9. rename volume in nimble gui and bring online
  10. rescan all
  11. configure R/R on connected volumes - right click manage paths,
  12. re-issue command above per kb59
  13. re-issue block reclamation command
  14. set up volume protection on renamed vmfs