VMware vSphere Update Manager (VUM) is an easy to use tool, that is embedded with the vCSA since version 6.5. With VUM, an ESXi host can be updated with updates for the hypervisor (build version), but also for specific drivers or vibs that support the hardware. This can be done by using the standard repository of VMware and / or repo’s of external parties like HPE. With VUM, you can also upload separate Images & Vibs that can be included in your update patchline.

Pros:

• Reliable VMware tool, that can show compliancy by creating different baselines
• Possibility to update and install different vibs through Repo’s or uploading zip files.
• It was quite clear that updating an ESXi host is best done by VUM, but after the tests, we consider to be the best tools for pushing drivers as well. This is because VUM give you more control, when pushing drivers towards an ESXi host compared towards the other tools. With VUM, you can change the versions of the drivers, and if it comes from an official Repo, it will be checked for compatibility with the current ESXi version.
• With VUM you can easily see if your host are compliant or not by using your own baseline. This way, you are certain that the ESXi hosts have the same build version and the ESXi updates are installed.
• When your ESXi host all have the same Hardware Model, you can be quite certain that everything is consistent and all the  ESXi updates & driver are pushed equally through VUM.
• VUM has a check if certain drivers are compatible and applicable for your ESXi host. This is definitely not done with any of the other tools.

Cons:

• The baseline doesn’t explicitly say if a driver is installed or updated. The compliancy check only checks IF the update is applicable, and then if it is installed. If VUM consider it as n/a, then it doesn’t count towards the compliancy check.
• With a defined baseline, you can check if the important updates are installed and if all the host are consistent in that. However, you cannot easily check if your environment is truly consistent with every installed vib version. Everything that is not named in the baseline, is not checked for compliancy. Also, if someone updated a vib manually and that vib package ends up with a higher vib version then your current baseline, chances are that the vib in the baseline will not be pushed. This can create inconsistency within the environment between other hosts, which is difficult to check.
• Not able to push firmware. This was expected and should therefor be performed with tools of HPE.
• VUM has a check if certain drivers are compatible and applicable for your ESXi host, but it doesn’t seem to check if the Installed Firmware is applicable as well.

Points of interest:

• 1*: Updates & Vibs within a baseline are not always being pushed if VUM consider the vib or version as not applicable. This means that a compliancy check only checks the possible installed vibs. All the vibs that are not possible are ignored for the compliancy check. This can give a wrong assumption that everything is updated and installed.
• 2*: Drivers of the vendor have to be installed through the Vendor Repo. With HPE, the vibs are scattered through different Repo’s with different URLs. In this case HPE should do the check if the driver is compatible with a certain ESXi version. Unfortunately, this doesn’t always seem to be the case, and sometimes it marks a driver unrightfully as n/a or even for a different ESXi version that is actually not officially supported. Going to the site of VMware, you can do a manual  check if the firmware, ESXi and driver version are supported together. But this also means that you have to download and check the vib manually.
• 3*: ESXi host seem to be firmware aware through the CIM agents. Still, when installing a separate vib, it doesn’t seem to be checked against the firmware version of HPE. Even though VMware has that information in their knowledge base.
• * Together with Kabir Ali, we found a way to make a report through Powercli, which will check the environment for consistency. More about this script will be discussed in the upcoming post. 

HPE Smart Update Manager (SUM) is a tool that can only be used by downloading a SPP from the HPE site. Once you open the SPP, you can make use of the tool known as SUM. With SUM you can make connections to HPE hardware and deploy SPP’s towards it. *Fun fact, once you open the SUM tool within the SPP, you can select a different SPP that you want to deploy towards the server, both higher or lower version. This can be handy when a certain SUM version seems to have problems with making a connection or deployment.

SUM can be really handy, but in opinion, can’t be considered as an enterprise tool. This is because it can take quite some time to set up all the separate connections. This wouldn’t be a problem, if these connections could be easily setup, imported and or shared between colleagues. Instead, using SUM can quickly become a manual job of adding hardware every time you want to update something. The reason for this is, because SUM makes use of an user profile. Change the user, and you’ll lose all the settings. Same goes for using a higher version of SUM by changing the SPP. Once you use a newer or other SUM version, you have to configure all the connections again.

Pros:

• Comes with the SPP and doesn’t need an appliance to push updates. This can be quite handy for quick deployments
• Can Push Firmware towards different types of hardware
• Can Push drivers to ESXi host (CIM agents required).
• Can Push Drivers through SSH, no ILO required.
• Online Staging possible.

Cons:

• Can’t be considered as an Enterprise tool. It is easy for a few servers, but not for hundreds of them.
• Versions of installed drivers is difficult to view, and no compatibility check is performed. Therefor recommend deploy drivers through VUM to be sure to have a more reliable outcome.
• No checks at all if the Firmware or drivers are supported on the ESXi hosts. This was expected, but this also means that I wouldn’t trust the tool for pushing firmware updates without checking compliancy on the VMware website first. Same goes for drivers. Driver updates are best handled through VUM.
• No reporting tool or method to check your hardware for firmware version consistency across your environment.

Points of interest:

• As said earlier, this tool comes with the SPP. The version of the SPP determined the version of the SUM tool. Unfortunately, this can also bring some problems. During different deployment, we’ve noticed several times that with the combination of some types of hardware and SUM versions, connections couldn’t be established through the ILO. Establishing a connection to the ESXi host with SSH was most of the time not a problem, but this is only applicable for the driver updates.
• It seems that both OneView & SUT uses SUM under the hood. Weirdly enough, if SUT fails with updating, SUM can most of the time still do the trick.

HPE OneView is more then a LCM tool, and in a certain way you actually could compare it with a vCenter Server. It is the management tool for all the different HPE hardware. Through it, you can push Firmware updates and drivers. HPE OneView has different dashboards and views that help you navigate towards all the different types of hardware and settings. This way, you can generate a “form” of overview or you can narrow done to each component. The reason I say “form” of overview, is because it doesn’t really give you that great of an overview. It is quite confusing and unfortunately there is no easy way to view and compare the firmware of the different hardware. You can see the firmware of all the components for lets say, a blade. However, to do that, it seems that you really have to go to each individual blade. There is no easy way to view the firmware of all the components together with the other blades, which I find quite disappointing. There is a “general” version overview, but that doesn’t show the overview of each component.

We also found out that pushing Firmware updates and drivers with HP OneView is quite unreliable. Several times, the same kind of servers, with the same type of hardware, profile and SPP, ended up with different types of firmware versions. The more annoying part is, that there is almost no mention of it. As I said earlier, there is also no easy way to check if the firmware was successfully updated, which I found quite a shame for a tool with such a potential. To only way to be sure, is narrow done to each specific component. So even though OneView seems to have all the required information at hand, it is simply not capable to give you a simple comparison report or alarm if certain updates are not installed.  It simply just doesn’t do it. There are quite some things that OneView does really well. But when we check the overall tool, it is an incomplete tool. More importantly, it is not always accurate & consistent. It is unfortunate to say it, but for the LCM part, HPE OneView lacks the most basic  and simple features of reporting. Which makes it therefor difficult to manage a big or enterprise environment.

Pros:

• Great tool to quickly manage all the different types of HPE Hardware, and getting a “general” overview of the HPE Stack in your environment.
• Can Push Firmware towards different types of hardware.
• Can Push drivers to ESXi host (CIM agents required).
• Server Profiles for blades “can / could” be really helpful.
  • With a Hardware Profile, specific settings are stored in OneView (Mac Adresses, WWN’s etc.) This should make it easy to replace a blade with a new one, without reconfiguring Virtual Connects or Storage settings.
• Server Profile Templates “can / could” be really helpful.
  • With a Server Profile Template, you can push easily a newer SPP towards all the other Server Profiles. Also you can push certain BIOS settings, and make it consistent through all the blades. This way, you can push General Server settings without going to each Server Profile individually.

Cons:

• Honestly, the tool is too unreliable when pushing updates, and therefor a manual check afterwards is required. The tool is especially unreliable on a large scale.
• I have seen too many times that the profile of blades are lost or not being pushed after an update, which gives all sorts of problems after the ESXi is booted up. Think of different mac addresses, WWNs for Storage, etcetera. This happened to an awful lot of servers, and it is really time-consuming to fix. This is a personal experience, but with 128 blades I think I have enough reference material to say that this problem is quite consistence. At least with a certain model that is officially supported by HPE.
• Updating a blade is still a manual and intensive process. Sure, you can push a SPP towards different types of hardware at the same time with a “Server Profile Template”, but applying the update is still done by selecting each component separately. This is the same problem with SUM, only the difference is that HP OneView has to connections already configured.
• You cannot stage it online (not without SUT at least).
• No checks at all if the Firmware or drivers are supported on the ESXi hosts. This was expected, but this also mean that I wouldn’t trust the tool for pushing updates of firmware without checking compliancy on the VMware website first.
• Versions of installed drivers on the ESXi host is (almost) impossible to view. Therefor recommend to do this through VUM to be sure and to have a more reliable outcome.
• My biggest problem of HP OneView, is the lack of notifying if something was wrong or wasn’t successfully configured or installed. For example, you can push a “Server Profile Template” towards a set of “Server Profiles”. After quite some time, it says “update complete”. The only thing the “Server Profile Template” then actually did is updating the “Server Profile” settings. This does NOT update the blades with the latest settings. It will say that the “Server Profile Template” is consistent with the “Server Profiles”, but like I said, consistency does not say anything if the server actually has the “Server Profile” pushed. You still have to push that part manually. After you reapplied the settings towards the blade, there is once again, no way to check if the settings were pushed towards the blade. This is quite problematic, since I have already noticed an enormous amount of times that the settings were not pushed, while HP OneView acts that everything is ok and has completed the request. Like I said earlier, this problem is not only with settings but it is also with pushing Firmware.

Points of interest:

• SUT is an extension of HP OneView which makes pushing firmware updates more bearable.
• HP OneView can be considered as a management tool that has the option to update the environment. It has a lot of potential and can be really helpful, but in general it is quite clunky, and not being able to make simple reports with all the information that is available is quite a shame.
• * Currently, I found a way to make a report through Powershell, which will check the environment for consistency. This has been made in cooperation with HPE. More about this script will be discussed in the upcoming post.

The last tool is the “Smart Update Tools”.
SUT can be seen as an extension of HP OneView. It is a little bit more flexible, and it gives you an easy option to stage hardware online and beforehand. This can be really easy when you want to update the complete stack in one go. This way you can push both the Firmware, ESXi updates & Drivers, and reduce the amounts of reboots needed.

I would be really happy if I could say SUT is a big game changer, and that it is a big and positive addition to HP OneView, but unfortunately it is not. It is a tool that seems to be developed only to give a little bit more flexibility towards the deployment for Gen 9 and lower Servers. With several upgrade deployments towards multiple servers, we’ve noticed that the update towards certain blades, randomly quite. Fun thing is, that in those moments, we had to fix it with SUM.

Do note that SUT can only be used with HP OneView, it cannot ran separately. 

Pros:

• Online Staging.
• Gives a little bit more flexibility to the HP OneView suite.

Cons:

• Same limitations as HP OneView.
• Still haven’t found an easy and reliable way to use the tool. For large deployments, we’ve noticed that it could stop halve way the deployment. The reasons for this still has to be confirmed by HPE.
• Can’t update the BIOS.

Points of interest:

• The tool cannot run without OneView.
• Still seems to make use of the original SUM that is in the SPP.
• Doesn’t seem to be used with Gen10 or higher. There they use iSUT, but cannot officially confirm that since I’ve never test it. Still I think it is worth mentioning.