Intro
Life Cycle & Patch Management within organizations can be a difficult topic. Mostly because of the broad set of software and hardware that can and should be included in a Life Cycle & Patch Management strategy. Still, due to the constantly changing landscape within the IT, this becomes more and more important. Security breaches are more and more common, and with the rise of exploits like spectre, meltdown but also atacks of ransomware like cryptolockers, IT and organizations have been target heavily since the last 5 years. Data breaches are happening more often, and with stronger regulations on data security, this has become a hot topic for a long time. Besides security updates, Life Cycle Management is also important for receiving bug fixes or new features that help organizations to become more flexible and agile. Luckily, organizations are getting more and more aware of these facts, and the “if it ain’t broke, don’t fix it” mentality is surely but slowly dying out.
Now the reasons for starting this blogpost and probably also series, is because several customers seem to have problems with keeping their hardware and software up-to-date. One of our customers didn’t’ updated his environment for over 3,5 years. In this case, I defined a Roadmap that helped them to update and upgrade their VMware vSphere environment, but also their complete HPE stack to the latest possible versions. Now while we are at the last bits and pieces to finish off this project, I felt that I couldn’t leave this customer without defining some form of plan. A plan that helps them to keep their environment up-to-date for the next several years. While exploring the HPE stack more in-depth during the project, I came to several cool, but also unpleasant surprises. These series will be primarily focused on keeping a VMware environment up-to-date that is running on a HPE stack, by using several different tools offered by VMware & HPE.
Let’s begin.
Basics Firsts
Alright, first things first. Before we can define a LCM plan, we have to know how a complete stack is build, and how the components can influence each other within the stack. We’re going through the basics and discuss the following topics:
- Hardware & Components,
- Firmware,
- SPP (HPE),
- BIOS,
- Components,
- ESXi Updates (VMware)
- Drivers & CIM agents
Hardware
Lets start with the hardware, it is the stuff that makes everything possible. A server is build of different components. This can be: a motherboard, Processors, RAM, NICs, HBA’s, GPU’s, HDD/SSD’s, and an out-of-band management (OBM) component. With HPE, the OBM is the so-called ILO. Hardware Vendors, create a specific and predefined sets of hardware out of these components, that we most of the time also know as a Model, Type and / or series. With a specific Server Model, the vendor is sure that the hardware is aligned and perfectly in tune with the other components, and therefor knows that it performs and acts in a certain way. With HPE, these servers can be managed through the ILO. The ILO is a component that almost stands completely on itself. When the server is powered down or even crashed, the ILO makes it possible that the server can still be reached and managed (most of the time 😉). Now for most of you this is well known knowledge, but it is important to start from the beginning.
In the past, servers were most of the times stand-alone machines. Nowadays it is more common that the server is part of an enclosure or of a hyper-converged infrastructure (HCI). The server is or can be referred then as a blade. Within the enclosure, the blade makes use of shared components, which can be things like the Power Supply, but also Network Adapters. These enclosures can also be managed (Through the ILO), and does also needs to be updated. The same goes for the network adapters. With HPE these network adapters within the enclosure are also known as “Virtual Connects”. The Virtual Connects have virtual adapters profiles for each blade and presents it towards the blade as a physical adapter. Similar what VMware does with vmkernel adapters.
BIOS & Firmware
Hardware needs software to be used, and the first step in that is the “Basic Input/Output System”, also known as the BIOS. The BIOS manages all these components and also makes it all work together. It is also the component that starts before an OS is loaded. When all the checks are done, the BIOS will ask the bootloader to boot up the installed Operating System. The BIOS itself can be updated from time to time, but it also happens les often.
When we update individual hardware components we generally call that Firmware. Each component that was listed up earlier in the hardware section, needs firmware. Firmware can be updated to enhance security or to make use of new features and code sets.
With HPE, Firmware is mostly updated through the Service Pack for Proliant (SPP). The SPP is an image that can be used in multiple ways to update the firmware of the different components.
Hypervisor: ESXi Updates, Drivers & CIM Agents
An Hypervisor like ESXi, is nothing more than an Operating System, that makes use of the hardware. Just like a Windows machine, an ESXi host needs drivers to make use of the hardware. Driver versions are (or should be) based on the installed firmware version that is presented on the hardware layer. This is quite important, since an Operating System is depending on drivers to make the hardware work, it needs to be compatible with the installed firmware version.
It is important to note that within VMware, you can patch an ESXi host with new updates and towards a higher ESXI version. This doesn’t mean that these updates contain drivers or driver updates. Updates within an ESXi host are most of the time focused on the Software code of the Hypervisor itself. Drivers are most of the time separately selected and installed and are also downloadable from a different repository then the standard repo. VMware sometimes makes use of some general type of drivers, and these are also sometimes updated from within the standard Repo.
With HPE hardware, you can also make use of CIM agents that can be installed on the ESXi host. The CIM agent makes the Hypervisor more aware of the used hardware and firmware. Vice Versa, it can make a tool like HPE SUM also aware of which drivers there are installed on the ESXi host itself. When using a standard HPE ISO, CIM agents are always included, but when using a Standard VMware ISO, these should or can be installed separately.
The generic term Update
Last but not least, I want to make a clear distinction of using the word update. Updates are a generic term, which can cause a lot of confusion. When talking about updating, this can mean different things for different people, depending on the field or specific area you are looking at. For instance, HPE Hardware can be updated, but when I do, I explicitly talk about the firmware that is updated. When an ESXi host is updated, we can focus on updating the code of the hypervisor or the drivers that it contains. However, when we talk about an ESXi update, we actually always refer toward and update of the code of the OS. Which result in a higher build number and version of the ESXi host. For instance going from ESXi 6.5u1g to 6.5u2c. Now it is important that drivers within the hypervisor are not necessarily automatically updated, even though it can be done with the same tool that we use for the ESXi update. Therefor drivers are considered as a separate part of the OS, and is explicitly named driver update. This will hopefully make it more clear about which part we are talking about.
Now that we got that out of the way, let’s talk of how we should upgrade these different parts within a simple Server Setup, or when we upgrade a Server that is part of a Blade Enclosure (HPE).
Update Order of a Server
Later in these blogposts, we will talk more in-depth about the process and order of how we could update a vSphere environment on a HPE stack. For now, a quick and simple overview of in which order we generally update the infrastructure.
Simple Setup, Stand-alone Server:
Blade –> BIOS update (If Needed) –> Firmware Update Component(s) –> ESXi Update (Version / Build) –> Drivers Update.
Blade Enclosure Setup (HPE):
- Onboard Admin Enclosure –> Firmware & ILO update
- Virtual Connect –> Firmware update
- Blade –> BIOS update (If Needed) –> Firmware Update Component(s) –> ESXi Update (Version / Build) –> Drivers Update
It is important to note that both the ESXi version as the driver version needs to be compatible with the firmware of the Hardware & Model.
That’s it, we covered all the basics. In the next post we’re going to talk about all the different Tools that are available to update and manage these types of environment.
Samir is the author of vSAM.Pro & a Life enthusiast who works as a consultant in the field of IT. With a great passion for Tech & Personal Development, he loves to help people with their problems, but also inspire them with a positive outlook on life.
Besides that, he is also a big Sport & Music junky that loves to spend a big chunk of his time on producing music or physically stretching himself.
