Learn about VM hardware upgrade procedures and why it is important to keep VM hardware upgraded.
- [Instructor] We already took the time to look at upgrading VM tools. Let's take some time now, to look at VM hardware. Now VM hardware is nothing more than the software box that makes up a virtual machine. This is what pretends to be hardware, so that an operating system can actually be placed inside the virtual machine and run. So there are upgrades as we go along. Version 11, version 12, and now with 6.5, we're in version 13.
So when we upgrade that software box, we are improving the version. We're using better software that makes up the box that is the virtual machine, itself. So what happens when we do upgrade this box? What does it allow us to do? Well first off, it improves overall performance of the virtual machine. It runs more efficiently. We also are allowed for feature sets for the newer versions. If you have an older vCenter server that's trying to control a virtual machine, or a holder host that's trying to control a virtual machine with a higher hardware version, that leads to issues.
Because it may not have the same feature sets. So this leads to a compatibility difference between vCenter server hosts and the actual virtual machines. It is a best practice to use the hardware version that matches your host and vCenter server that you've implemented. Like I said, for version 6.5, we're looking at a hardware version of 13, 6.0 was hardware version 12. Now whenever we upgrade the hardware on a virtual machine, this is going to require a restart.
Now this hardware upgrade can be done with Update Manager. This is actually what I believe is best practices, here. So use Update Manager, apply that baseline we talked about and then it requires a restart before that actually takes place. And you can configure Update Manager to go ahead and automatically upgrade the hardware once the virtual machine is restarted. So this doesn't have to be a task that you set for it to do without being prompted, right? You could just set it up so whenever that virtual machine is restarted, for whatever reason, it'll automatically take care of the upgrade as well.
Now let's talk about some of the reasons we might want to do this versus why we might not. Like we said earlier, we're going to see improved performance and expanded feature sets. Now, the bad part about this you might have a legacy OS that's working on a hardware version. And if you're running older versions that's working on a particular hardware version of a virtual machine, I like to keep that right where it is. I mean, sometimes I'll clone it and test it in my lap to see if I can upgrade the hardware version without any issues, but if it isn't broke, I don't like to try and fix it for legacy operating systems.
Also, like we said, it can get a bit weird when we start using different versions. If I'm using a vCenter server from 5.5, it's going to be really tough to have the same features and everything that it's involved in hardware version 13 for a virtual machine, or a virtual machine that was created under 6.5. And last but not least, the bad is definitely guaranteed downtime. Now, we can check our hardware version at the summary page of our inventory item, So you select the virtual machine, you go to the summary page in the information pane.
You will see what the hardware version is. Like we said, 6.5 has a hardware version of 13, 6.0 has a hardware version of 12. Remember I said we have inconsistent control when the versions don't match. So if I have vCenter server 5.5, and I have virtual machines that were created under a ESXi 6.5 version the control there is going to be a little bit lacking, we're not going to have the same feature sets, it doesn't work well. So please, best practices, your hardware version should match your ESXi version that's been implemented.
And last but not least, this is a very important part of this lesson. Unless required, or downtime is scheduled, 99.99% of the time, I'm going to let this go. This is because if I have a higher version of vCenter Server 6.5, I can control hardware versions below version 13, pretty accurately. But it doesn't work the other way. Now why would I not be proactive about updating my hardware? Well, that's because it has inherent downtime.
If we're going to update the hardware, we are at least going to need to restart. So that's downtime built in. I'm a fan of uptime, not downtime. So, because Update Manager allows us to schedule this to happen whenever the machine is rebooted, instead of forcing it to happen now, I like to set this up to say, Okay, I'm going to put a hardware upgrade in place, but I don't want it to take place unless we need to restart a virtual machine for some other reason.
And last but not least, remember to test, test, test, before implementation into your production environment. Nine times out of ten, this won't be an issue. Usually I like to test my legacy operating systems. My newer operating systems I'm pretty sure will work fine. But I do like to test, test, test just to make sure.
- Manually performing ESXi host and virtual machine upgrades
- Configuring a custom download source for Update Manager
- Importing ESXi images
- Creating baselines or baseline groups
- Attaching baselines to vSphere objects
- Upgrading an ESXi host using vCenter Update Manager
- Upgrading VMware tools, VM hardware, and Update Manager
- Performing vCenter server upgrades