Welcome back to vSphere 8 in the real world. And now we're going to discuss Lifecycle Manager.
So Lifecycle Manager can be used to patch our ESXi hosts and it can be used to update or
perform upgrades or updates on our ESXi hosts. Now, Lifecycle Manager replaced Update Manager,
which Update Manager was at the time, you know, when it first came out, we could use to do some
patching on our ESXi hosts. We could patch our VMs. That was one of the big, you know,
selling points there. We could use it to actually patch like our Windows VMs and some things like
that. VMware, I think, pretty quickly realized that there's a lot of tools already out there
that customers are already using for patching their Windows systems, including their VMs.
And they didn't need to provide a tool for patching those operating systems. That was already
being done through some other tool. And then they also, at the same time, I think, realized that
there were some weaknesses in that tool for updating, patching the hosts because we could,
you know, install patches on the hosts themselves. But like, for example, you know,
drivers weren't updated, BIOSes could not be updated and things like that. And VMware wanted
to focus more on the hosts themselves and less on the operating systems that were already being
managed by other tools that customers use, you know, pretty broadly. And so we moved to Lifecycle
Manager. And now with the current version of Lifecycle Manager, we can patch our hosts,
we can perform upgrades on our hosts, and we can even update things like BIOS and things like that.
So they can actually download, you know, BIOS updates and drivers and things like that for
third-party providers like Dell systems and HP systems and update those for us also. So because
VMware is able to update the BIOS on our hosts, it also knows, okay,
I can make sure this host is at this firmware level in the BIOS, so I know that these features
of the operating system will also be supported. So I'm not going to install this software and
these features until the BIOS is at this level as well. So it actually made it for a very nice,
stable, consistent environment for VMware to run on. So that's a pretty great feature right there.
All right. So we can, you know, before we didn't want to have to do like a bunch of manual work,
it's very much automated now. So Update Manager was around 2007 and got replaced, like I said,
by Lifecycle Manager. All right. So it's been rebranded a few times, but the new thing now
is we have our vSphere Lifecycle Manager, and in vSphere 8, we can use it for patching our hosts
and for patching things like BIOS. So not enough to just patch our hosts, like we mentioned before.
We also need to make sure our hardware things are up to date, our BIOS is up to date and things
like that. And our hosts, you know, have current drivers, which, you know, the VIBs from that came
from VMware. They've always come from VMware. So we can always update the VIBs on the operating
system for ESXi. But if we wanted to make sure that we have this BIOS version for this device,
this firmware for this device, and then we want this VIB, this driver to match with it,
now VMware has that level of control over it. And that's one of the great things about
Lifecycle Manager is not only can we patch our operating system, we can do BIOS, and we can do
upgrades as well. And upgrading is actually a really nice feature. So it's pretty easy,
because now as part of Lifecycle Manager, the upgrade process can be automated to where
it will automatically put a host in maintenance mode, automatically evacuate the VMs off of there,
and then push out the update, and then we can go to the next host in the cluster. And the next host
in the cluster just keeps that process going. It makes updating go much, much smoother than it did,
previous to this Lifecycle Manager feature.
So a cluster software management, meaning that we are able to do things like,
it's going to be vSAN aware. It also is obviously our regular cluster aware.
So it can do things like put hosts in maintenance mode. It can also do a vSAN maintenance. So we can
evacuate VMs off of a vSAN node. It can also evacuate VMs off just the regular compute node,
get a node available to be upgraded. So this is real deeply integrated in with our vSphere
environment now. And we can tell the system where it needs to be. Basically, by where it needs to
be, meaning it will say, okay, out there in the world, I see that VMware has 8.0, 8.0 update one,
update two, update three, and all the different versions of update three. And you can say,
we're going to standardize this cluster on this version of 8.0 update three,
whatever, whatever kind of thing. And you can pick that. So you can really say specifically
where you want to be in the VMware cycle, and then make sure all your hosts are patched to that level.
So one nice, straight image. You can just find a golden image too. So rather than say,
I just want to be on a version of vSphere, you can say, okay, I have gone into this host,
and I installed this version of ESXi I want. I patched to this level. Everything's exactly
how I want this host. That's my golden image. And then you can create an image from that,
and it will say, okay, I'm going to make sure all the other hosts match that image. I'll make sure
all the hosts have the same drivers and the same OS version, all the same, everything on there
as your golden image. So this makes it easy for you to standardize. I don't have to configure
30 hosts and hope I get them all exactly right. I have to configure one exactly right,
and the other 29 can be automatically configured to match that. So if you didn't want to use a
specific base image from VMware, you need to tweak it somewhat. Maybe a certain driver
wasn't working with your device as well in your environment, so you need to have this image,
but with this different driver on it, you could customize that and make that your golden image.
And then go through, check your host for all your documentation. One thing nice about it too is,
again, if you have some kind of compliance need and they need to know how do you control
patching, how do you make sure all your hosts are patched to a certain level,
how do you make sure that certain published vulnerabilities have been patched and things
like that, you can say, oh, because we go to here and you can see here, this is what our image has,
this is what our image is about, and then you can tell that our 30 hosts are all compliant
with that image, with those patches, and that's how we maintain that. We maintain that
by keeping our image up to date, and we maintain that by pushing out automatically to that image,
and then we can have a report sent to us also saying, are we or are we not in compliance with
that? So, if you have compliance needs, this can make compliance much easier. It's really kind of
a pain to have to say, oh, we are in compliance because we go to every host and we run this
report on each host and we check these boxes on an Excel spreadsheet for each host, and then we
verify, you know, that's obviously kind of ridiculous, right? This makes it really easy
to automate that across the board, all right, and tell you what's in compliance, what's not,
and then to push it all to be in compliance. Hardware verification, again, make sure your
hardware is on the hardware compatibility guide. vSAN has a different hardware compatibility list
than the operating system does, right? You can say ESXi in general has this hardware compatibility list,
but if you want to run vSAN, there's other components that also need to make sure you have,
you know, compatible for vSAN to be compatible with. If you're not running vSAN, those items
don't need to be checked. If you're running vSAN, you need to make sure you've got a controller
that is, you know, on the compatibility list for vSAN and some things like that.
And so, what I mean by that is, this is just one example, RAID controllers, right? vSAN does not
want this presented as a big, single RAID array. It doesn't want you taking your 15 disks in this
host and creating a RAID anything, not a RAID 0, not a RAID 1, not a RAID 5 or 6. It wants you just
to present all the disks as just raw disks. So, RAID controllers now that are designed to work
with vSAN, if they can do RAID, they can do a RAID 0, RAID 5, or RAID 6, or RAID 10, whatever
you want. So, you can install another operating system and use that RAID controller, or they can
also just be into like a physical compatibility mode where they just present the disks, right?
They are not doing any kind of RAID controller at all. They're just presenting the disks to the
operating system. And then ESXi will see 15 disks, and then vSAN can treat those 15 disks how it
wants. It can create their pools with the disks and things like that and put VMs on disks the
way that vSAN wants to run vSAN. So, that's an example of, you know, an older RAID controller
wouldn't have that functionality that vSAN needs. And so, make sure your RAID controller is
compatible with vSAN. ESXi may not care about that at all if you're not running vSAN, right?
So, a RAID controller that can't do that is compatible with ESXi, but it's not compatible
with ESXi running vSAN. Just kind of keep that in mind. Make sure that you know if you're running
vSAN that you need to do additional checks other than just the ESXi hardware compatibility list.
So, here we're seeing we have a bunch of hosts, right? And our hosts are all running an older
image. We have our golden image, and then we have all these old images. And they may be the same
as an older golden image, or they could all be different. I could have four different
configurations, four different images, four different, you know, sets of, you know, drivers
and things like that out there. And I want to get it all the same. I want all my hosts patched to
the same level, running the same version of ESXi, with the same drivers, all the same bibs,
all the everything, right? So, we can go and we can create that golden image.
We can say we want to sync the golden image with the host. So, the first thing you're going to do
is you're going to go there and just tell it to compare and tell me in a report which ones are
in compliance and which ones aren't, and maybe none of them are. Then we can tell it we want
to remediate that. We want it to go through, and we want to make them all match. So, we can
make them all match. And it will go through each one. It'll evacuate the host. It'll put it in
maintenance mode. It'll push out the drivers and do, you know, all that kind of updating.
And then it's going to reboot it, and then it's going to come back up again, and it'll take it
out of maintenance mode. And you can tell it to do the whole cluster, and it'll go through one
at a time and do that. Many times, I'm a little bit, you know, gun shy about doing that because
I don't want the system to think everything's great, and it has happened before where I updated
a host, and vCenter said everything was fine, and the VMs on that host were just not running well.
They were running. They were running poorly. There was all kinds of, you know, performance issues,
and I had to evacuate the VMs off that host, reboot again, and then it came up fine, right?
I've also had upgrades that just went sideways, and the host wouldn't come back up again. But
vCenter would know that, and it wouldn't put VMs on there. Sometimes, there's problems that vCenter
doesn't know about, and it starts putting VMs back on hosts. So, I like to kind of do one-by-one
myself and kind of keep an eye on it. I've been in environments, though, where that's just not
practical. I've been in environments where, you know, there's just dozens and dozens and dozens
of hosts, and we don't have time to sit and babysit each one. And so, we'll just go into a
cluster, do a cluster, monitor, make sure everything's okay, make sure all the things
are performing well before we let it do the next cluster. That's just been my experience. So,
most of the time, 99% of the time, upgrades go without a hitch. But that one time that it doesn't,
that you get phone calls and people are upset. So, just be a little bit cautious, but I would
definitely trust the process. I've had good luck with it across, you know, in general, with few
exceptions. So, using the Lifecycle Manager, we can define a golden image, right? We can use a
host to go in and be our base image for that. We can select the ESXi version we want to be our base.
We can also add to an image things like vendors, like vendor add-ons. We can say,
these are Dell servers. These are Dell R, you know, 810s and this and that and that kind of thing.
And we need to have this compatible with that, with that image. And it'll get all the right
drivers for our vendor and all that stuff and make that part of our base image for us, okay?
After we've gone through and we've created that image, then we want to go through and check our
cluster, right? We want to check our cluster and make sure that it's in compliance with our image.
And when it's a brand new image, it obviously won't be, right? If it's not in compliance,
then Lifecycle Manager can go through, show us which ones are, which ones are not. And then we
can say to remediate. And again, that remediation means putting the host in maintenance mode,
patching, rebooting, taking it out of maintenance mode. And then a service like
DRS could go in and start putting VMSec on there for us.
So, finishing the image setup. So, once we've gone through, we can save it to our cluster.
And we'll see that you can, you know, that, yeah, you can have an image attached to a cluster.
Go and remediate. If there are issues, you can do remediation. After you do your remediation,
then run the check again just to make sure that everything did apply. You could also check each
host as it's going along and go into the logs and check the logs. You can go to the host.
And at the host level, you can say remediate or check just this host. And is this host now
in compliance? You can do it that way as well. Here we can say you can export an image. So,
why would you want to export an image? Well, you might want to export an image because you've got
this vCenter, you know, image exactly the way you want. Maybe it took you hours to get it just
the way you needed it. Now you can export it, take it to another vCenter server. You can bring it in
there. And you can, you know, now apply that and reuse all that work you did in the first vCenter
and subsequent vCenters that are running the same hardware that you want patched the same level.
So, maybe we did this in our lab and our lab's tuned perfectly and we want to bring it into
production. Or we, you know, tuned it in a lab and now we've got 10 different production
environments we need to push it out to, that kind of thing. So, it's nice being able to export that
image and use it again somewhere else. So, host compatibility, verify the host
compatibility. You're going to use the host compatibility list. You also want to use the
vSAN hardware compatibility list like I mentioned, right? So, you want to use the hardware compatibility
guide or the VMware compatibility guide. And you want to use the vSAN hardware compatibility
list. And we discussed just a moment ago, you know, why they might be different. Run a compatibility
check. So, you can run this check beforehand. You'll see in our lab where we have these
ESXi hosts, our virtual machines, we're going to get a message that our processors aren't
compatible. We can still move forward. It won't be a problem for doing the demo. But you'll see
that it does check and make sure and says, oh, you know, you've got a problem with, you know,
the CPU. There's a problem with the HBA or something like that. You can sync your updates.
You can stage your updates, meaning that the system, the vCenter can actually push the updates
out to the host. They're staged there. But they're not going to be installed until you say you want
to actually remediate. And that way, if you wanted to say, okay, we're going to do this tonight and
we want to go as quick as we can, it's still going to take time. But you can save the time of copying
updates to the host and do that earlier during the day by staging them first. Okay. And then you
can say if you want, if you're going to, you know, sync with the HCL or not. Okay.
So, upgrades suite for electrical manager. So, we can push out entire updates. Rather than just
doing patches and that, you know, saying, okay, here's a new security update available for our
ESXi host, we can say we want to actually do a full operating system. So, if we're running on
8.0, you know, update one, we want to go to 8.03 or something like that. Right. Download the ISO.
And then we can go through. We can say we want to upgrade. Man, oh, here's with vRealize. We can use
vRealize. So, that's what the whole lifecycle manager suite part is about, is that we're pushing
that through vRealize. Okay. So, vRealize, basically, it's just an automation tool to where
I don't have to go to each cluster and the vCenter and things like that. vRealize allows me to do
pretty much all the same checks that we would normally do, but we can do them on a bigger scale,
attach to multiple vCenter servers, and we can automate this, you know, pushing the things out,
pushing the images out to multiple vCenters and clusters and things like that all at the same
time. So, and we can upgrade our system using vRealize and the upgrade suite lifecycle manager
that's in vRealize. All right. So, again, all the same things. You can check if the upgrade's needed,
select what version you want to be on. It's going to find the ISO, say, yep, here's the ISO
we're going to use to push this out to the host, and then you can go through and you can start your
patching. So, some known issues when you're upgrading. So, if you're upgrading vCenter
and using lifecycle manager, you might need to go in and reset the lifecycle manager database.
We discussed this when we talked about upgrading vCenter before, too. If we're going from, like,
version 7 to version 8, lifecycle manager might kind of hiccup on you during that upgrade. So,
all we need to do is connect to the vCenter server shells or an SSH into the vCenter server,
and we're going to stop the update manager service. We are going to basically go in and
run a command to reset the database. Then we're going to delete all the patches that are in the
patch folder for the update manager, and then we're going to restart the update manager service.
And when we restart the update manager service, it's going to check in with VMware's website again,
download all the updates, rebuild that database, and then we can say, okay, now we got this all
rebuilt. This is the patch level that we are configured for, and we can start, you know,
updating and pushing things out again after we've updated vCenter.
So, we discussed lifecycle manager. We discussed some improvements to lifecycle manager.
We discussed using lifecycle manager for patching and upgrading. We discussed host
compatibility. You want to make sure that the various components on your host are compatible
with lifecycle manager with ESXi specifically, and also if you're using vSAN, compatible with vSAN.
And we discussed a known issue known with upgrading your vCenter server and lifecycle manager.