HOWTO: Install QLogic QConvergedConsole beside HPE 3Par SSMC and Veeam Backup & Recovery

Ok – I’ll admit it – I’m something of a vendor snob…  And my vendor of choice when it comes to Ethernet and fibre channel host connectivity is QLogic and HPE’s OEM products made by QLogic.  You just can’t beat the price or performance of the offerings, and the support that QLogic’s HPE OEM team gives you – they are second to none (a huge shout out to @ToddOwens_QLGC & Jim Burton – if you guys are reading this, thanks for all the amazing support over the years!).

One of the interesting things about QLogic is their branded applications generally work hand in hand with the OEM products they offer to various system manufacturers such as HPE, Dell, and Lenovo.  While I was attending a storage conference last week, I sat in on a presentation Jim and Todd were hosting.  During the presentation the talk turned to QLogic’s comprehensive adapter management tools, including the Web-based QCC (QConvergedConsole), which is supported on Windows, Linux, and Solaris.  QCC allows you to modify and configure your adapters (Ethernet, iSCSI, FCoE, and FC), upgrade the flash on them, perform FC ping and traceroute, and to view reports, statistics, and diagnostics of all the QLogic devices in your equipment – either locally or remote.

Given that QLogic devices are generally so bullet proof, and that the HPE Support Pack for Proliant takes care of my firmware updates, I rarely have a need to install and use QCC.  But today was a little different – I had a VMware host that suffered a Purple Screen of Death overnight, and while I was in the ILO power cycling it and looking for a reason for PSOD, I noticed that ILO was complaining that the 534FLR-SFP+ adapter was degraded because it was in FCoE mode and not connected (we don’t use FCoE).  Since I didn’t want to waste any more time playing around with the host before I brought it back online, I decided that I would load QCC on my management server at the site and see if I could disable FCoE mode remotely.

I never did find a way to disable the FCoE function via QCC – I only spent 3 minutes looking at it, so there may well be a way if I actually RTFM (that isn’t my style though), but this post isn’t about that.  This post is all about getting QCC to co-exist (temporarily anyways) on a server that already has HPE’s 3Par SSMC and / or Veeam Backup & Recovery installed on it.  QCC has been around a long time – longer that both SSMC and VBR, and as such has a few port conflicts that the guys at HPE and Veeam never took into consideration.  As a result, you can’t just fire up the QCC installer and expect it co-exist and run 7/24 right out of the box along side SSMC and VBR.

Once you have the QCC installer downloaded and extracted, there are a few things we need to do before firing up the installer.

First, lets check to make sure TCP ports 8080, 8443, and 111 are not in use.  We can accomplish this by opening an elevated command prompt and running:   netstat -ano | find “”


In the example above, you can see that two of the three ports are in use.  Port 8443 is used by the application that has a PID of 38692, while port 111 is used by the application that has a PID of 30000.  Using Task Manager, or better yet my favorite tool for the job – Process Explorer, we can easily determine the applications that are hogging these ports if we enable the PID and Path columns and then sort of the PID.


So to get started, we need to stop (temporarily) SSMC and VBR’s vPower NFS service.



Now that we have stopped these two services, lets double check to make sure TCP ports 8080, 8443, and 111 are no longer in use.


So with all three ports now free and no longer in use, we can launch the QCC installer as Administrator (note – all screen snapshots are based on Windows 2012 R2 with QCC v5.4.0.41).  Click next a couple of times until you get to the “Please enter desired port number”.  This defaults to TCP 8080, which as we checked already above, is free to use, so go ahead and click Install.


Eventually the installer will prompt if you wish to restrict access to localhost.  No one else at my sites require access to QCC, so I’m ok with restricting access – I clicked yes (note it defaults to no, so if you just hit enter you answered no…)


Eventually, you’ll be prompted if you wish to enable security login.


Since this application is only going to be enabled temporarily when I actually need it on the management server on the management VLAN, and because I am restricting access to the localhost only, I left the checkbox cleared.  That said, you may wish enable security – and if you do, make sure you make a note of the credentials you set!  The default login id credentials if you didn’t change them is “QCC” with a password of “config”.  Click Next to continue.

Now you are prompted if you wish to enable SSL.  That is likely a good idea, even if you are restricting it to the localhost – so click yes.  This will automatically set the Tomcat7 engine to use TCP 8443 and you can not change this from the installer.


Finally you will be presented with the Done button.


Take note of the URL as you will need it shortly…  https://localhost:8443/QConvergeConsole/ or http://localhost:8080/QConvergeConsole/

Now we can go ahead and install the necessary management agents.  In my case I am going to install all of the management agents.


After we click Next, you’ll notice that the installer is installing the ONCPortmap service.  This runs on TCP 111.  If TCP 111 is already in use, the installer will hang, and hang, and hang…  This is why we stopped the Veeam vPower NFS service earlier.


Eventually the management agent will complete the install process.  When we install the next management agent, you’ll notice a warning about the ONCPortmap service – this is good!  It means the ONCPortmap installed and started successfully.


After we have all the management agents installed that we want or require, we can go back in the command prompt and check our port status again.


Now you can see that all three ports are in use – which means QCC is likely ready to go.  Sort of…  As I mentioned previously, because the ports used in QCC conflict with SSMC and Veeam vPower NFS, we can’t just leave things alone and expect all three apps to work in the future after a reboot.  In my environment SSMC and Veeam are more important than QCC, and I always want them to be started after a server reboot.  So we need to set the follow services to be manual start instead of automatic (which they are by default) so they don’t prevent SSMC or Veeam from starting.

  • ONC/RPC Portmapper
  • QLManagementAgentJava
  • QLogic Management Suite FastLinQ
  • QLogic Management Suite Java iQAgent
  • QLogicManagementSuitenQLRemote
  • Tomcat7

Once we have changed the startup type of these services to manual, then lets login using the URL we were shown above.


Now – in the Host Selection dialog box, type in localhost and hit the connect button.  You should be able to safely ignore any errors you may see.


Finally – the console is opened!  Lets make a simple cosmetic change to see if it works (so something that does not affects the performance or anything of the adapters).  Highlight one of the ports of one of your adapters (in my example below, Port 0 of the HP 533FLR-T) and click on the MBA Boot Cfg tab in the right hand pane.  In the Hide Setup Prompt drop-down box, pick the opposite of whatever is there (it is probably already disabled, so select enabled), then click the Apply button.


You’ll be prompted for a password.  This password, assuming you made no changes to the default setup will be “config”.  If you aren’t sure if this is correct, clear the checkbox that says save password.  If you leave it checked, and the password you put in is wrong, then you will need to log out of QCC and back in to be able to try a different password.


If you had the correct password, you’ll see a green banner advising you of a successful update!


Now all that is left is to make the changes you actually set out to do!  Of course, once you are finished, you have two choices – reboot the server to apply the changes and have SSMC and VBR startup on reboot, or ignore the reboot, manually stop all the QCC services (see the list above) and manually start the SSMC and VBR services.

Now that you have QCC installed, if you need to access it in the future, you can just stop SSMC and VBR, then start the necessary QCC services.  While it isn’t a perfect solution, it will allow QCC to coexist along side both SSMC and Veeam’s vPower NFS service.

As always – Use any tips, tricks, or scripts I post at your own risk.

HOWTO: Replace a failed 3Par drive

HPE 3Pars are great arrays, but just like any other storage system, they do occasionally end up suffering a failed hard drive.  Replacing a failed 3Par drive isn’t quite the same as replacing a failed Proliant Smart Array controller drive – there are a few manual steps that need done to facilitate the replacement process, which I am going to detail below (note – I’m using a StoreServ 7200, based on OS 3.2.1 MU2 as my reference in this post).

First, SSH (via Putty) the 3PAR’s management IP and login as 3paradm (remember the username and password are case-sensitive).

At the 3PAR_SN# cli% prompt, type:    showpd -failed -degraded

This should show you the failed drive and it’s ID (in the example below, the drive hasn’t totally failed, but rather is just degraded due to an internal loop error in the drive, so it needs replaced).

2016.05.24 - 09.15.46 - SNAGIT -  0026

Next, see if servicemag has been issued or is running with:   servicemag status

If servicemag is not running, you will see:   No servicemag operations logged.

Now we want to see if the data has been evacuated off the drive already by running this command:   showpd -space 15   (where 15 is the drive ID that needs replaced).   Using the output shown below, double check there is no data left on the drive. You need to check that all columns other than size and failed are zero.  As you can see from the example , this drive still has data on it (again because the drive in this example is only degraded, not failed – my experience is that typically failed drives have 0, 0, 0, 0 for volume, spare, free, and unavailable, while failed is usually equal to the size).

2016.05.24 - 09.15.54 - SNAGIT -  0027

To evacuate the data, run this command:    servicemag start -pdid 15     and answer yes when prompted if you are sure you want to run it.

2016.05.24 - 09.56.05 - SNAGIT -  0033

To check the status / progress of the servicemag command, run:    servicemag status

2016.05.24 - 09.16.14 - SNAGIT -  0029

As you can see above, 4 chunklets (1GB blocks of disk space) have been moved off the drive so far, with another 107 chunklets (107 GB) to evacuate.  Below is what you will see once the servicemag process has finished.

2016.05.24 - 09.16.23 - SNAGIT -  0030

Before continuing, verify there is no data left on the drive by running:  showpd -space 15

2016.05.24 - 09.16.28 - SNAGIT -  0031

When the HPE field engineer arrives onsite with the replacement disk, you may need to turn on the locate light on the failed drive for him.  To do this, run:      locatecage -t XX cageY ZZ    where TT is time in seconds (i.e. 300), and Y in cageY is the cage number shown above, and ZZ is the magazine number to locate (i.e.  locatecage -t 300 cage0 15 enables the flashing locate light for 5 minutes for the failed drive that is being referenced in this HOWTO).

Once the drive has been replaced, the 3Par **should in the background** run an admitpd automatically for you.  To verify this, run:   showpd -p -mg ZZ -c Y     to see if the new drive is listed (note it will most likely have different drive ID than the dead drive)

When you have verified the new drive has been seen and admitted, you can check the rebuild status with servicemag statusYou can see below the rebuild process, followed by the status message once servicemag as successfully finished.

2016.05.24 - 09.16.52 - SNAGIT -  0032

If you go back to the HP 3PAR Management Console and refresh the console, you should find the fail drive no longer appears (it will stay there appearing as failed even after it has been removed from the cage until the rebuild process is completed, at which point it will go away).

If the HP 3PAR Management Console indicates a firmware update needs performed on the replacement drive, run:   upgradepd ZZ    and answer yes when prompted.  Refresh the HP 3PAR Management Console when the upgrade is complete to check for any other errors.

If no further errors appear, the drive replacement process is completed.  If there are errors, then escalate back to HPE with your original case number.

As always – Use any tips, tricks, or scripts I post at your own risk.

HOWTO: Make a 3Par RJ45 serial console cable for an OpenGear ACM5004 Remote Site Manager

On all the 3Par StoreServ 7000/8000 nodes we manage for our clients, we utilize OpenGear ACM5004-F-E Remote Site Manager (basically a serial console switch) so that we can remotely access the serial console on the nodes (in case a node is shutdown to the SMI Whack prompt or something else silly is going on).  The ACM5004 has 4 x RJ45 serial ports on it, which are a Cisco Straight pinout.

Just plugging a standard patch cable into the ACM5004 and the back on the StoreServ node isn’t going to work.  And using the RJ45/DB9 couplers that the 3Par ships with is both a pain in the butt, an eye sore, and bulky.  So I set out to build my own custom RJ45 cable.

On the 3Par end, use pins 2 (orange), pin 3 (blue), and pin 5 (green). Be sure to label this end as the 3Par end!!! I attempt to always put a small tiewrap (which is white in the photo below and hard to see thanks to a blurry photo) around this end of the cable to mark it as the 3Par 3nd.

On the ACM5004 end, use pins 3 (blue), pin 5 (green), and pin 6 (orange). Be sure to label this end as ACM5004!!!

Plug the 3Par end into the node’s serial console port, and the other end into the ACM5004.  After configuring the ACM5004, SSH it and connect the appropriate port on the ACM5004 and you should now see your 3Par serial console.

3Par End
ACM5004 End