vSphere 5.5 – Solution for VASA setup errors with VNX

Over weekend I wanted to review some of the features and functionalities that VASA and VSI provides inside vCenter server for a VNX array(5300).  VASA configuration should be straight forward but ran into some strange issues which took some extensive troubleshooting:


VMware compatibility guide for EMC VASA provider specifies that VASA support is part of VNX Block OE 05.32; no additional software is required.  Our VNX 5300 has FLARE 5.32 which should allow for straight connectivity to the VNX…

On vCenter server web client select your vCenter server in inventory list on left.  Select Manage tab in right pane -> Storage provider sub-tab. Click the green button.

URL for direct VNX block:
URL for direct VNX file:
URL for SMI-S:

When trying to connect directly to VNX block I received the following error message:

In vCSA i reviewed the following error messages in sps.log under \var\logs\vmware\vpx\sps\
“Received fatal alert: unknown_ca”

The most common issue that seems to be related to the VASA configuration is a expired certificate for the storage monitoring server.
This can be verified with the following commands on vCSA:
# cd /etc/vmware-vpx/ssl/
# keytool -keystore sms.keystore -storepass testpassword -list -v
Check the valid from and until in the output provided.
This was NOT my issue.

To further test this I installed a windows 2012 server with SMI-S. Same connectivity errors appeared.
So what is going on here!

Some further troubleshooting was in order:
– I regenerated the storage management certificates and restarted the vCenter server appliance
– I restarted the array’s management server.
– I added the vCenter server certificate to trusted certificates on VNX
– Verified the user created on VNX has VM administrator role.
– For user authentication if you create a local user on VNX, then be sure to add local\username for authentication in service provider.
– Verify that there is an array connected to SMI-S.  this can be verified by running the command “symcfg list” or logging in with testsmiprovider.exe and executing “dv” command.

Still no luck.
Looking further at the sps.log file I figured the problem had to be with the vCenter server that is sending the certificate to the array.


I sticked with SMI-S since it provides more customization in administration console.
    Username and password the same   (admin / #1Password)
Under security select “SSL Certification Management.
Here we want to select option 3 and import CA certificate from file…

So which certificate do we import?  well that would be the sms.keystore cert, but we need the cert as PEM data.  Do this perform the following commands on vCSA:

# cd /etc/vmware-vpx/ssl/
# keytool -importkeystore -srckeystore sms.keystore -destkeystore /tmp/sms.pkcs -srcstoretype JKS -deststoretype PKCS12
# cd /tmp
# openssl pkcs12 -in sms.pkcs -out sms.pem

Now open the sms.pem in and editor and copy the information from —Begin Certificate— to —End Certificate—
Paste into the textbox to submit the CA to SMI-S.

Now in vCenter service provider, setup connection to SMI-S again.


"Boot from SAN" step by step with Windows 2012 R2 and Cisco UCS using Brocade and EMC VNX.

“Boot from SAN” step by step with Windows 2012 R2 and Cisco UCS using Brocade and EMC VNX.
  • Create service profile for windows server.
  • Create “Boot from san” boot policy
    • Setup SAN primary and secondary target.
    • The WWN required are that of your VNX array ports.

  • Login to create an initial zone for one of the ports.
  • Create new Alias
    • Type in the Alias name and select the WWN from blade
  • Create zone
    • Select the blade Alias and VNX Storage processor
  • Add to Zone configurations
  • Activate

  • Start EMC Unisphere
  • Create Initiator
    • WWN/IQN can be obtained from UCS director
      • Open properties window for service profile of server
      • Select storage tab
      • At top copy the World Wide Node Name  (this is the first part of WWN/IQN)
      • Under vHBAs copy the WWPN
    • Now combine the WWNN and WWPN and with “:” as separator paste into WWN/IQN
  • Select “New Host” radio button
    • Type in the server name and IP address
  • Create LUNs
  • Create Storage Group per server
    • Associate the hosts
    • Associate the LUNs
  • Start the server and boot from Windows disk
  • Load the UCS disk drivers when asked for during installation and selection of the installation disk.
  • Verify disks show up and select where it will be installed.
  • After installation is completed and Windows is up and running, go ahead and install EMC Powerpath!

VNX MnR: Not showing SAN data after upgrade

Recently ran the upgrade of VNX monitoring and reporting from version 1.2 to 2.0.

Upgrade completed successfully but after logging in and viewing the data we were unable to view the file storage information.


  • Verify NaviSECCLI path is correct in VNX MnR Config 

  • If the above is correctly configured, attempt updating NaviSecCLI to latest Version (Found on EMC Support Site under downloads if you search for NAVISECCLI)
  • Once Installed issue any command to accept the certificate from VNX This is only required if NAVICLI version is updated 
    • Open Cmd Prompt and issue any NAVI CLI Command to be prompted to accept certificate

Commvault – Backup Copy of snapshot for Exchange 2010

Been running into an interesting scenario with a backup process which I hope will help someone else.
I have an exchange backup of DAG with intellisnap which creates a snapshot of each of the exchange database volume on Netapp.  The snapshot is then mounted and copied via SAN transport on the backend fiber connection to the storage library on commvault agent.
This has a storage policy to perform a backup copy of the latest snap via SAN transport weekly on Thursdays.
With commvault I find that sometimes the snapshots are not copied to the commvault storage library, without any type of error.
In viewing the jobs for the primary copy of snaphost i just shows a status of “to be copied”, but no failure.
This however causes problems since if you do not pay attention you can sit with weeks of uncopied backup copies of the snapshots, and if you snapshots are set for retention of a few days then you loose all those copies and have to mark them bad! (not good!)
Have not find a way to resolve this, even with the help of Commvault support, but here are a few tips to make sure you are at least inform in more detail regarding this process:
  • A good indication that the backup copy is not taking place is when the snapshots on netapp volume is not being deleted.
  • Also make sure you setup a very detailed report for the day after the snapshot copy was to take place and make sure the backup copy detailed information is also included in this report.

If however you do run into this problem, and your snapshots have already been rotated on the volumes on storage you would have to perform the following tasks to continue the backup copy process.
(I recommend contacting Commvault support if you are not familiar with your storage, snapshots and intellisnap, the steps below are provided for use at your own risk, you will loose backup data with these steps)
  • Verify you oldest snapshot date which are still on volumes for databases
  • Select storage policy
  • Right click and primary copy and select view -> jobs
  • this will list all the backup copies and show the ones with status “to be copied”.
  • Select all jobs up to before the date you have for snapshots on Netapp volume.
  • Right click and select “Mark job bad” (i know not my favorite step)
  • Right click on the storage policy again and select All Tasks -> Run Backup copy.
  • This will start the backup copy of your latest snapshot which resides on backup storage volume
Another solution is to manually add snapshots taken during the week to be added for backup copies.

  • Right click on the storage policy again and select View -> Jobs
  • Right click on the snap you want to create backup copy off.
  • Select “Pick for backup copy”
  • As a note, you cannot create a backup copy of snapshot which is older than your latest backup copy. so make sure you backup your oldest snapshot first . 
Anybody else running into the same problem would love to hear from you.