This is one stop global knowledge base where you can learn about all the products, solutions and support features.
You may need to identify the LUN (Logical Unit Number) from a NAA (Network Addressing Authority) identifier for a number of processes. (One or more numbers may reside between the first set of six digits and the last set of 24 digits).
The LUN serial number is included as part of the NAA. From the serial number, you can then identify the LUN ID.
The first six digits in an NAA refer to Pure Storage. The last 24 digits refer to the LUN’s serial number.
Example NAA: naa . 624a93 7 0 a78e6e1d4bacd0960001001a
In the above example:
The first six digits , 624a93 7 , highlighted in blue for emphasis, is the identifier for Pure Storage, verifying its origin in a Pure Storage device.
The last 24 digits, a78e6e1d4bacd0960001001a , highlighted in green for emphasis.
(In the example, one digit resides between the two sets of digits that are relevant here).
From a list of pure storage volumes, identify the LUN ID from the serial number. For example, if you were to identify the LUN ID from the serial number above, you could enter the following command:
pureuser-ct0:~# purevol list
This result would follow:
CLFDEV01_26 2T - 2014-05-27 15:05:41 EDT A78E6E1D4BACD0960001001A
Of this result, the first section of digits, CLFDEV01_26, is the LUN ID, which corresponds to both the serial number and the NAA.
For information on identifying LUN IDs from a FlashArray, see Identifying LUNs (Logical Unit Numbers) from Purity to Correlate to a Host.
This guide shows how to re-scan and examine FC LUNS on Solaris 10/11. This is required for detecting new LUNs and to assist with basic storage connectivity troubleshooting.
Re-scanning FC LUNs on Solaris is generally non-disruptive in a well configured environment with normal load.
The following commands are useful for general SAN stack fact-finding on Solaris:
root@Unixarena-SOL11:~# luxadm -e port |grep CONNECTED /devices/pci@1d,700000/SUNW,qlc@1,1/fp@0,0:devctl CONNECTED /devices/pci@1d,700000/SUNW,qlc@3/fp@0,0:devctl CONNECTED
Unix@sol# cfgadm -al -o show_FCP_dev |grep fc-fabric c2 fc-fabric connected configured unknown c4 fc-fabric connected configured unknown Unix@sol#
fcinfo
command:
Unix@sol# fcinfo hba-port |grep Port HBA Port WWN: 10000000c884bb48 HBA Port WWN: 10000000c884bb49 HBA Port WWN: 10000000c884b85c HBA Port WWN: 10000000c884b85d Unix@sol#
luxadm
command, if HBA is already connected to the FC switch.
Unix@sol# luxadm -e dump_map /dev/cfg/c4 Pos Port_ID Hard_Addr Port WWN Node WWN Type 0 29900 0 50080e8008cfb814 50080e8008cfb814 0x0 (Disk device) 1 27400 0 10000000c884b85c 20000000c884b85c 0x1f (Unknown Type,Host Bus Adapter) Unix@sol#
From the above output, the last line shows the HBA information. In the same way you can find the other controller information as well.
Unix@sol# cfgadm -al -o show_FCP_dev c2 c4
Unix@sol# cfgadm -c configure c2::50080e8008cfb814 Unix@sol# cfgadm -c configure c4::50080e8008cfb814
| Scanning for FC/SAN Devices | |
|---|---|
cfgadm -al
|
To scan FC LUNs |
devfsadm -c disk
|
To make sure all the device files are created |
tail /var/adm/messages
|
To see the new LUNs information |
echo | format
|
To get the new LUNs information |
ls -lrt /dev/rdsk | grep s2 | tail
|
To get the new LUNs information |
Note
: The command
luxadm
probe
can also be used to scan FC LUNs.
If you are still unable to see the new LUN/DISK, then, if you have multipathing enabled, you can try to reset the HBA. (Do not try this in critical servers unless you are confident that multipathing is correctly configured)
root@Unixarena-SOL11:~# luxadm -e port |grep CONNECTED /devices/pci@1d,700000/SUNW,qlc@1,1/fp@0,0:devctl CONNECTED /devices/pci@1d,700000/SUNW,qlc@3/fp@0,0:devctl CONNECTED
forcelip
option:
root@Unixarena-SOL11:~# luxadm -e forcelip /devices/pci@1d,700000/SUNW,qlc@1,1/fp@0,0:devctl
The
forcelip
command can be issued to the controller names as well:
Unix@sol# cfgadm -al -o show_FCP_dev |grep fc-fabric c2 fc-fabric connected configured unknown c4 fc-fabric connected configured unknown Unix@sol# Unix@sol# luxadm -e forcelip /dev/cfg/c2
cfgadm -al
. Make sure disks didn't loose any SAN paths after the HBA reset. If everything seems to be working, then issue the
forcelip
command to the other controller as well.
If you are still not able to see the new FC/SAN LUNS, then, as a last resort, reboot the server and try again. Once you see the new LUN, make sure that you also see all FC paths. A minimum two FC paths is required for SAN disks.
root@Unixarena-SOL11:~# luxadm display /dev/rdsk/c1txxxxxxd0s2
The following commands are useful for general SAN stack fact-finding on Solaris:
root@Unixarena-SOL11:~# luxadm -e port |grep CONNECTED /devices/pci@1d,700000/SUNW,qlc@1,1/fp@0,0:devctl CONNECTED /devices/pci@1d,700000/SUNW,qlc@3/fp@0,0:devctl CONNECTED
Unix@sol# cfgadm -al -o show_FCP_dev |grep fc-fabric c2 fc-fabric connected configured unknown c4 fc-fabric connected configured unknown Unix@sol#
fcinfo
command:
Unix@sol# fcinfo hba-port |grep Port HBA Port WWN: 10000000c884bb48 HBA Port WWN: 10000000c884bb49 HBA Port WWN: 10000000c884b85c HBA Port WWN: 10000000c884b85d Unix@sol#
luxadm
command, if HBA is already connected to the FC switch.
Unix@sol# luxadm -e dump_map /dev/cfg/c4 Pos Port_ID Hard_Addr Port WWN Node WWN Type 0 29900 0 50080e8008cfb814 50080e8008cfb814 0x0 (Disk device) 1 27400 0 10000000c884b85c 20000000c884b85c 0x1f (Unknown Type,Host Bus Adapter) Unix@sol#
From the above output, the last line shows the HBA information. In the same way you can find the other controller information as well.
Unix@sol# cfgadm -al -o show_FCP_dev c2 c4
Unix@sol# cfgadm -c configure c2::50080e8008cfb814 Unix@sol# cfgadm -c configure c4::50080e8008cfb814
| Scanning for FC/SAN Devices | |
|---|---|
cfgadm -al
|
To scan FC LUNs |
devfsadm -c disk
|
To make sure all the device files are created |
tail /var/adm/messages
|
To see the new LUNs information |
echo | format
|
To get the new LUNs information |
ls -lrt /dev/rdsk | grep s2 | tail
|
To get the new LUNs information |
Note
: The command
luxadm
probe
can also be used to scan FC LUNs.
If you are still unable to see the new LUN/DISK, then, if you have multipathing enabled, you can try to reset the HBA. (Do not try this in critical servers unless you are confident that multipathing is correctly configured)
root@Unixarena-SOL11:~# luxadm -e port |grep CONNECTED /devices/pci@1d,700000/SUNW,qlc@1,1/fp@0,0:devctl CONNECTED /devices/pci@1d,700000/SUNW,qlc@3/fp@0,0:devctl CONNECTED
forcelip
option:
root@Unixarena-SOL11:~# luxadm -e forcelip /devices/pci@1d,700000/SUNW,qlc@1,1/fp@0,0:devctl
The
forcelip
command can be issued to the controller names as well:
Unix@sol# cfgadm -al -o show_FCP_dev |grep fc-fabric c2 fc-fabric connected configured unknown c4 fc-fabric connected configured unknown Unix@sol# Unix@sol# luxadm -e forcelip /dev/cfg/c2
cfgadm -al
. Make sure disks didn't loose any SAN paths after the HBA reset. If everything seems to be working, then issue the
forcelip
command to the other controller as well.
If you are still not able to see the new FC/SAN LUNS, then, as a last resort, reboot the server and try again. Once you see the new LUN, make sure that you also see all FC paths. A minimum two FC paths is required for SAN disks.
root@Unixarena-SOL11:~# luxadm display /dev/rdsk/c1txxxxxxd0s2
For instructions on installing and updating the plugin from the Pure GUI see VMware vSphere Plugin Install (Version 3.0 | Version 2.5 or Older).
If after following the documentation for VMware vSphere Plugin Installation and the plugin still does not function properly, this is often due to the VMware vSphere web client server not supporting TLS 1.1 or 1.2. See Analyzing the vsphere_client_virgo.log below if you would like to confirm this.
The PluginServer was developed because other troubleshooting steps such as adjusting the wrapper.conf file, updating Java, or manually installing the plugin can cause other unexpected issues in the customer's environment. If the following does not work create a Jira do not try other steps without directions from PSE.
The procedure below does a few different things. It runs the
unregisterplugin sh/bat
using the IP address of the vSphere server. It commands this server to stop its attempt to download the vSphere plugin from our array through the API and then attempts installation of the plugin. The next time a user logs into the vSphere web client, the web client triggers the plugin's installation when a user logs in. If there was a failed attempt to prevent login from taking a long time, it will not try and install the plugin twice. Restarting the vSphere Web Client service resolves this. Next, the
startserver
enables the API to pull the needed files from the Windows or Linux OS. And finally, the
registerplugin
uses API to pull the needed files to the vSphere server and tell vSphere to install the plugin the next time someone logs into the vSphere web client.
If any of these steps do not work see the notes section below.
mkdir [drive:]path/pluginserver
.
cd pluginserver/
.
copy ../PureStorage_vSphere_installer.jar /pluginserver
.
unregisterplugin.bat
, while in the folder where the extracted files and the PureStorage_vSphere_installer.jar resides.
startserver.bat
in the command console used for creating the directory. This will start up the web server that hosts the plugin. Keep this console open and running while you perform the rest of the steps.
robm$ ./startserver.bat Found these arguments port(8080) keystore(keystore.jks) File location(purestorage-vsphere-plugin.zip) Starting server on port 8080... Server started successfully!
registerplugin.bat
while in the directory where unzip extracted the pluginserver and the PureStorage_vSphere_installer.jar resides.
C:\Program Files\VMware\vCenter Server\bin>service-control --stop vspherewebclientsvc
C:\Program Files\VMware\vCenter Server\bin>service-control --start vspherewebclientsvc
Now have the user log into the vSphere web client to see the PureStorage plugin, if it is there, you can now close both command line windows.
8. If we still do not see the PureStorage Plugin make sure they have logged out then back into the vSphere Web Client.
9. If we still do not see PureStorage Plugin proceed to Analyzing the vsphere_client_virgo.log (steps below).
Once the user has logged into vSphere Web Client and can see the plugin, follow the vSphere Web Client user guide.
vCenter Server Appliance VCSA requires another OS to run the pluginserver scripts on. This can be another temporary VM running Linux or Windows, the following instructions are for a linux VM. Follow the above Windows steps if this other OS is running windows OS.
If any of these steps do not work see the notes section below.
mkdir pluginserver
.
unzip -d pluginserver/ Pluginserver-2.5.1_201704051804+163c8cd-rel_2_5_x.zip
.
cd pluginserver/
.
cp ../PureStorage_vSphere_installer.jar ./
.
chmod a+x *.sh
.
Enter ./unregisterplugin.bat, while in the directory where unzip extracted the files and the PureStorage_vSphere_installer.jar resides.
./startserver.sh
.
robm$ ./startserver.sh Found these arguments port(8080) keystore(keystore.jks) File location(purestorage-vsphere-plugin.zip) Starting server on port 8080... Server started successfully!
robm@ubuntu:~$ sudo apt-get update robm@ubuntu:~$ sudo apt-get install default-jre
registerplugin.sh
while in the directory where unzip extracted the PluginServer and where the PureStorage_vSphere_installer.jar resides.
service vsphere-client restart
.
Locate the vsphere_client_virgo.log and have the customer copy them to a text file then email them to us. These logs often get zipped up and numbered so be sure we have the file for the time period of when we attempted to install the plugin. Below is where these files should be located. Often this file is not where we expect it to be so searching it may be necessary. The following is from this vmware kb.
Search the vsphere_client_virgo log for when the plugin was attempted. Usually, it will say “purestorage” when the attempt to install was performed. The following are errors we have seen in this file.
[2016-02-11 16:06:03.213] ERROR [ERROR] http-bio-9443-exec-16 com.purestorage.FlashArrayHelper javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
This alert was from not having JDK 1.8 see this JIRA.
[2017-06-19 10:34:00.954] [ERROR] vc-service-pool-2169 70002699 100142 200004 com.vmware.vise.vim.extension.VcExtensionManager Error unzipping https://192.168.41.131/download/pure...?version=2.5.1 to directory C:\ProgramData\VMware\vSphere Web Client\vc-packages\vsphere-client-serenity\com.purestorage.plugin.vsphere-2.5.1, check if the server process has Write Permission on this machine. java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
This alert is due to vSphere trying to establish communication with the array using TLSv1.0 ES-27873.
If installing from the GUI and it does not work and you see the above messages, install the PluginServer. If the vSphere server resides on a windows OS the PluginServer can be installed on it as described above. If the Linux VCSA appliance is being used we can put the PluginServer on a windows OS server (vm or bare metal) or a Linux vm as described above. Make sure this is not a production Linux VM as we may need to update or install java to 1.8+.
If any of these steps do not work see the notes section below.
mkdir [drive:]path/pluginserver
.
cd pluginserver/
.
copy ../PureStorage_vSphere_installer.jar /pluginserver
.
unregisterplugin.bat
, while in the folder where the extracted files and the PureStorage_vSphere_installer.jar resides.
startserver.bat
in the command console used for creating the directory. This will start up the web server that hosts the plugin. Keep this console open and running while you perform the rest of the steps.
robm$ ./startserver.bat Found these arguments port(8080) keystore(keystore.jks) File location(purestorage-vsphere-plugin.zip) Starting server on port 8080... Server started successfully!
registerplugin.bat
while in the directory where unzip extracted the pluginserver and the PureStorage_vSphere_installer.jar resides.
C:\Program Files\VMware\vCenter Server\bin>service-control --stop vspherewebclientsvc
C:\Program Files\VMware\vCenter Server\bin>service-control --start vspherewebclientsvc
Now have the user log into the vSphere web client to see the PureStorage plugin, if it is there, you can now close both command line windows.
8. If we still do not see the PureStorage Plugin make sure they have logged out then back into the vSphere Web Client.
9. If we still do not see PureStorage Plugin proceed to Analyzing the vsphere_client_virgo.log (steps below).
Once the user has logged into vSphere Web Client and can see the plugin, follow the vSphere Web Client user guide.
vCenter Server Appliance VCSA requires another OS to run the pluginserver scripts on. This can be another temporary VM running Linux or Windows, the following instructions are for a linux VM. Follow the above Windows steps if this other OS is running windows OS.
If any of these steps do not work see the notes section below.
mkdir pluginserver
.
unzip -d pluginserver/ Pluginserver-2.5.1_201704051804+163c8cd-rel_2_5_x.zip
.
cd pluginserver/
.
cp ../PureStorage_vSphere_installer.jar ./
.
chmod a+x *.sh
.
Enter ./unregisterplugin.bat, while in the directory where unzip extracted the files and the PureStorage_vSphere_installer.jar resides.
./startserver.sh
.
robm$ ./startserver.sh Found these arguments port(8080) keystore(keystore.jks) File location(purestorage-vsphere-plugin.zip) Starting server on port 8080... Server started successfully!
robm@ubuntu:~$ sudo apt-get update robm@ubuntu:~$ sudo apt-get install default-jre
registerplugin.sh
while in the directory where unzip extracted the PluginServer and where the PureStorage_vSphere_installer.jar resides.
service vsphere-client restart
.
Locate the vsphere_client_virgo.log and have the customer copy them to a text file then email them to us. These logs often get zipped up and numbered so be sure we have the file for the time period of when we attempted to install the plugin. Below is where these files should be located. Often this file is not where we expect it to be so searching it may be necessary. The following is from this vmware kb.
Search the vsphere_client_virgo log for when the plugin was attempted. Usually, it will say “purestorage” when the attempt to install was performed. The following are errors we have seen in this file.
[2016-02-11 16:06:03.213] ERROR [ERROR] http-bio-9443-exec-16 com.purestorage.FlashArrayHelper javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
This alert was from not having JDK 1.8 see this JIRA.
[2017-06-19 10:34:00.954] [ERROR] vc-service-pool-2169 70002699 100142 200004 com.vmware.vise.vim.extension.VcExtensionManager Error unzipping https://192.168.41.131/download/pure...?version=2.5.1 to directory C:\ProgramData\VMware\vSphere Web Client\vc-packages\vsphere-client-serenity\com.purestorage.plugin.vsphere-2.5.1, check if the server process has Write Permission on this machine. java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
This alert is due to vSphere trying to establish communication with the array using TLSv1.0 ES-27873.
If installing from the GUI and it does not work and you see the above messages, install the PluginServer. If the vSphere server resides on a windows OS the PluginServer can be installed on it as described above. If the Linux VCSA appliance is being used we can put the PluginServer on a windows OS server (vm or bare metal) or a Linux vm as described above. Make sure this is not a production Linux VM as we may need to update or install java to 1.8+.
If running the
startserver.bat/sh
script fails, there may be an issue when port 8080 is already in use. As seen below:
robm$Found these arguments port(8080) keystore(deystore.jks)
File location(purestorage-vsphere-plugin.zip)
java.net.BindException: Address already in use: bind”
robm$ ./startserver.sh
Found these arguments port(8080) keystore(keystore.jks)
File location(purestorage-vsphere-plugin.zip)
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:100)
at sun.net.httpserver.HttpsServerImpl.<init>(HttpsServerImpl.java:50)
at sun.net.httpserver.DefaultHttpServerProvider.createHttpsServer(DefaultHttpServerProvider.java:39)
at com.sun.net.httpserver.HttpsServer.create(HttpsServer.java:90)
at com.purestorage.PluginServer.main(Unknown Source)
Exception in thread "main" java.lang.NullPointerException: null SSLContext
at com.sun.net.httpserver.HttpsConfigurator.<init>(HttpsConfigurator.java:82)
at com.purestorage.PluginServer$1.<init>(Unknown Source)
at com.purestorage.PluginServer.main(Unknown Source)
To fix this error modify the startserver.bat/sh so it is using 8081.
Here is what the startserver.bat/sh looks like after modification:
#!/bin/bash set -e if [ ! -f /usr/bin/java ]; then echo 'Please install java' exit -1 fi # The listening port is 8081. You can modify to use any port. Make sure to modify the registerPlugin script. java -cp ./PureStorage_PluginServer.jar com.purestorage.PluginServer 8081 keystore.jks purestorage-vsphere-plugin.zip
Additionally, you will need to edit the registerplugin.bat/sh with the following command:
java -cp ./PureStorage_PluginServer.jar:./PureStorage_vSphere_installer.jar com.purestorage.RegisterPlugin 8081 3.0.0 $ip
Additional troubleshooting steps include:
registerserver
script, most likely the installer.jar isn't in the same directory as the unzipped PluginServer scripts.