It’s fair to say that I have not done any scripting for HP iLO since the release of their PowerShell scripting toolkit. I simply didn’t have a need. However in the past week I received a request to update my SSL Signing script for iLO to use the HP toolkit, and so I have.
As the HP cmdlets only support iLO3 and above, this script is also only compatible with iLO 3 and above.
The mechanics of the script depart from my previous scripts, in that they require a list of iLO interfaces in a text file, rather than doing DNS queries – this list should be a trivial thing to compile using Find-iLO HP cmdlet. It also no longer makes attempts to correct issues that may cause the certificate to not install correctly, it will simply note the problem and then list the skipped hosts in an exceptions report as the script completes. This greatly simplifies the script.
I’m making up some code using the HP PowerShell tools and one of the things I discovered is that it does not provide full support of iLO2. I’m not particularly surprised by this – iLO2 technology is nearly 10 years old, and we’re current at iLO4 in the newer model servers.
This may cause issues for some people with older hardware such as me. I was wondering for other HP Server Admins, what’s the iLO version in your environment?
Well, I am back in HP space for a little bit – configuring up a couple of HP c7000 chassis with some Gen8 blades. Being Gen8 they come equipped with an iLO4 interface and it has given me the opportunity to use the HP iLO mobile app. For the purposes of this article, this app was being used on an iPad Air with a bluetooth keyboard.
Having got my basic configuration into the blades I started adding them to the app, which was a little tedius having to re-enter the same credentials all the time. Dear HP, I would love a setting to be able to have a default or global credential store.
This can be worked around however, particularly if you are familiar with QR Codes. Making some assumptions that your server room is secure, you can print out QR codes for your devices with a string of hostname;username;password to put on servers, and then adding servers becomes a scan of the QR code using the app (or a paper based booklet of ‘codes’). The big problem here is that if you do not keep these QR codes secure, anyone with a QR code reading app can obtain login credentials.
As seen in the first image, I have a list of iLO interfaces. There are a couple of servers there with detailed information, and that is collected once you connect to the device for the first time. There is very limited organisation of the devices, with the ability to have a favourites list and thats about it. Dear HP, I would really like to see the ability to see folder organisation in future releases of this app. This will become unweildy with lots of devices.
It would appear that the Practical Admin Blog is read far and wide. This week I got an email from Product Marketing @ HP to let me know that they have released scripting tool for PowerShell recently. Needless to say this is a welcome announcement.
At just on 77,000 lines of code, it quite a substantial libraries of cmdlets, supporting iLO3 and iLO4 devices. In a somewhat strange decision there appears to be no supporting technical documentation linked to the PowerShell scripting tools, unlike the sample scripting tools available for perl & cpqlocfg tools. This has had to leave me delving into the code itself to get an idea what is available.
I am pleased to say that this library of cmdlets appears to have all the functionality my iLO libraries have in the past and would recommend to people have have iLO3 and iLO4 devices to look at this script, or replacing my own scripts with this one.
Having covered off on the methodology in Part 1 and the Bare Metal Results of Part 2, we now get onto what was perhaps the more controversial aspect of my testing where I worked – performance under a virtualisation platform. We primarily use VMware, and so the tests were done using this.
Disclaimer: The numbers obtained below are not indicative of the true performance of the server and should not influence any purchasing decisions made.
With virtualisation, I’m conservative and have a general expectation that I would see some minimal performance degradation of under 10%. The first tests we did consisted of creating an empty VM, and then running the PTS Live CD, as we thought this would rule out any disk I/O operations. I compared the results to the bare metal for each server and was surprised by the results:
When someone say’s their Virtual Machine is running slowly, the first thing we do is check out the performance graphs with the vSphere client. Everything looks normal, and so it is easy to dismiss it as an application issue. However, what happens when this issue is the result of a previously undetected problem that appears to have multiple components to it?
This is the problem I am currently working on now with a Dell R910 Server. The Dell R910s are quite a powerful machine designed for more intensive workloads and certainly comes as a surprise that we are seeings performance issues.
This is currently an issue being worked on, and I do not know what the outcome will be. However I will be documenting the steps being taken in order to benchmark performance and how we might improve the performance.
Having recently spent a week off-site to upgrade some blade chassis and add some new hardware, one of the more pleasant aspects of the upgrades was pulling some new HP BL460 Gen8 blades out of the box and turning them on. Not so pleasant was the fact they would not get past a POST, stopping with the following enigmatic error message:
1706 – The extended BIOS Data Area in Server Memory has been Overwritten – Smart Array Interrrupt 13h BIOS Cannot conitnue – System Halted.
What was worse was that this was happening to all four blades that I had inserted. Time to call HP.