WEBVTT 00:00:00.000 --> 00:00:04.320 Welcome back to vSphere 8 in the real world. And now we're going to discuss Lifecycle Manager. 00:00:06.880 --> 00:00:13.840 So Lifecycle Manager can be used to patch our ESXi hosts and it can be used to update or 00:00:13.840 --> 00:00:20.480 perform upgrades or updates on our ESXi hosts. Now, Lifecycle Manager replaced Update Manager, 00:00:20.480 --> 00:00:25.600 which Update Manager was at the time, you know, when it first came out, we could use to do some 00:00:25.600 --> 00:00:30.080 patching on our ESXi hosts. We could patch our VMs. That was one of the big, you know, 00:00:30.080 --> 00:00:34.799 selling points there. We could use it to actually patch like our Windows VMs and some things like 00:00:34.799 --> 00:00:39.520 that. VMware, I think, pretty quickly realized that there's a lot of tools already out there 00:00:39.520 --> 00:00:44.000 that customers are already using for patching their Windows systems, including their VMs. 00:00:44.000 --> 00:00:48.560 And they didn't need to provide a tool for patching those operating systems. That was already 00:00:48.560 --> 00:00:52.560 being done through some other tool. And then they also, at the same time, I think, realized that 00:00:52.959 --> 00:01:00.320 there were some weaknesses in that tool for updating, patching the hosts because we could, 00:01:00.320 --> 00:01:04.879 you know, install patches on the hosts themselves. But like, for example, you know, 00:01:04.879 --> 00:01:09.279 drivers weren't updated, BIOSes could not be updated and things like that. And VMware wanted 00:01:09.279 --> 00:01:15.120 to focus more on the hosts themselves and less on the operating systems that were already being 00:01:15.120 --> 00:01:21.040 managed by other tools that customers use, you know, pretty broadly. And so we moved to Lifecycle 00:01:21.040 --> 00:01:25.839 Manager. And now with the current version of Lifecycle Manager, we can patch our hosts, 00:01:25.839 --> 00:01:31.199 we can perform upgrades on our hosts, and we can even update things like BIOS and things like that. 00:01:31.199 --> 00:01:36.080 So they can actually download, you know, BIOS updates and drivers and things like that for 00:01:36.080 --> 00:01:43.839 third-party providers like Dell systems and HP systems and update those for us also. So because 00:01:44.959 --> 00:01:49.919 VMware is able to update the BIOS on our hosts, it also knows, okay, 00:01:49.919 --> 00:01:55.360 I can make sure this host is at this firmware level in the BIOS, so I know that these features 00:01:55.360 --> 00:02:00.559 of the operating system will also be supported. So I'm not going to install this software and 00:02:00.559 --> 00:02:05.120 these features until the BIOS is at this level as well. So it actually made it for a very nice, 00:02:05.120 --> 00:02:10.559 stable, consistent environment for VMware to run on. So that's a pretty great feature right there. 00:02:10.559 --> 00:02:14.639 All right. So we can, you know, before we didn't want to have to do like a bunch of manual work, 00:02:14.880 --> 00:02:22.800 it's very much automated now. So Update Manager was around 2007 and got replaced, like I said, 00:02:22.800 --> 00:02:27.119 by Lifecycle Manager. All right. So it's been rebranded a few times, but the new thing now 00:02:27.119 --> 00:02:32.960 is we have our vSphere Lifecycle Manager, and in vSphere 8, we can use it for patching our hosts 00:02:32.960 --> 00:02:42.240 and for patching things like BIOS. So not enough to just patch our hosts, like we mentioned before. 00:02:42.240 --> 00:02:45.839 We also need to make sure our hardware things are up to date, our BIOS is up to date and things 00:02:45.839 --> 00:02:50.880 like that. And our hosts, you know, have current drivers, which, you know, the VIBs from that came 00:02:50.880 --> 00:02:56.479 from VMware. They've always come from VMware. So we can always update the VIBs on the operating 00:02:56.479 --> 00:03:02.399 system for ESXi. But if we wanted to make sure that we have this BIOS version for this device, 00:03:02.399 --> 00:03:06.320 this firmware for this device, and then we want this VIB, this driver to match with it, 00:03:06.320 --> 00:03:10.080 now VMware has that level of control over it. And that's one of the great things about 00:03:10.080 --> 00:03:16.240 Lifecycle Manager is not only can we patch our operating system, we can do BIOS, and we can do 00:03:16.240 --> 00:03:20.479 upgrades as well. And upgrading is actually a really nice feature. So it's pretty easy, 00:03:20.479 --> 00:03:25.679 because now as part of Lifecycle Manager, the upgrade process can be automated to where 00:03:25.679 --> 00:03:29.839 it will automatically put a host in maintenance mode, automatically evacuate the VMs off of there, 00:03:29.839 --> 00:03:33.360 and then push out the update, and then we can go to the next host in the cluster. And the next host 00:03:33.360 --> 00:03:38.800 in the cluster just keeps that process going. It makes updating go much, much smoother than it did, 00:03:39.520 --> 00:03:41.759 previous to this Lifecycle Manager feature. 00:03:45.360 --> 00:03:49.759 So a cluster software management, meaning that we are able to do things like, 00:03:49.759 --> 00:03:54.479 it's going to be vSAN aware. It also is obviously our regular cluster aware. 00:03:54.479 --> 00:03:59.279 So it can do things like put hosts in maintenance mode. It can also do a vSAN maintenance. So we can 00:03:59.279 --> 00:04:05.520 evacuate VMs off of a vSAN node. It can also evacuate VMs off just the regular compute node, 00:04:05.520 --> 00:04:11.839 get a node available to be upgraded. So this is real deeply integrated in with our vSphere 00:04:11.839 --> 00:04:17.440 environment now. And we can tell the system where it needs to be. Basically, by where it needs to 00:04:17.440 --> 00:04:24.000 be, meaning it will say, okay, out there in the world, I see that VMware has 8.0, 8.0 update one, 00:04:24.000 --> 00:04:27.839 update two, update three, and all the different versions of update three. And you can say, 00:04:27.839 --> 00:04:33.359 we're going to standardize this cluster on this version of 8.0 update three, 00:04:33.920 --> 00:04:37.440 whatever, whatever kind of thing. And you can pick that. So you can really say specifically 00:04:37.440 --> 00:04:42.720 where you want to be in the VMware cycle, and then make sure all your hosts are patched to that level. 00:04:42.720 --> 00:04:49.040 So one nice, straight image. You can just find a golden image too. So rather than say, 00:04:49.040 --> 00:04:55.040 I just want to be on a version of vSphere, you can say, okay, I have gone into this host, 00:04:55.040 --> 00:05:00.160 and I installed this version of ESXi I want. I patched to this level. Everything's exactly 00:05:00.160 --> 00:05:05.519 how I want this host. That's my golden image. And then you can create an image from that, 00:05:05.519 --> 00:05:10.640 and it will say, okay, I'm going to make sure all the other hosts match that image. I'll make sure 00:05:10.640 --> 00:05:15.440 all the hosts have the same drivers and the same OS version, all the same, everything on there 00:05:15.440 --> 00:05:20.720 as your golden image. So this makes it easy for you to standardize. I don't have to configure 00:05:20.720 --> 00:05:25.760 30 hosts and hope I get them all exactly right. I have to configure one exactly right, 00:05:25.760 --> 00:05:31.119 and the other 29 can be automatically configured to match that. So if you didn't want to use a 00:05:31.119 --> 00:05:38.480 specific base image from VMware, you need to tweak it somewhat. Maybe a certain driver 00:05:38.480 --> 00:05:42.239 wasn't working with your device as well in your environment, so you need to have this image, 00:05:42.239 --> 00:05:46.799 but with this different driver on it, you could customize that and make that your golden image. 00:05:48.559 --> 00:05:53.279 And then go through, check your host for all your documentation. One thing nice about it too is, 00:05:53.279 --> 00:05:58.000 again, if you have some kind of compliance need and they need to know how do you control 00:05:58.799 --> 00:06:01.839 patching, how do you make sure all your hosts are patched to a certain level, 00:06:01.839 --> 00:06:05.839 how do you make sure that certain published vulnerabilities have been patched and things 00:06:05.839 --> 00:06:11.119 like that, you can say, oh, because we go to here and you can see here, this is what our image has, 00:06:11.119 --> 00:06:15.600 this is what our image is about, and then you can tell that our 30 hosts are all compliant 00:06:16.160 --> 00:06:20.320 with that image, with those patches, and that's how we maintain that. We maintain that 00:06:20.320 --> 00:06:26.000 by keeping our image up to date, and we maintain that by pushing out automatically to that image, 00:06:26.000 --> 00:06:31.200 and then we can have a report sent to us also saying, are we or are we not in compliance with 00:06:31.200 --> 00:06:36.399 that? So, if you have compliance needs, this can make compliance much easier. It's really kind of 00:06:36.399 --> 00:06:42.959 a pain to have to say, oh, we are in compliance because we go to every host and we run this 00:06:42.959 --> 00:06:47.359 report on each host and we check these boxes on an Excel spreadsheet for each host, and then we 00:06:47.359 --> 00:06:51.200 verify, you know, that's obviously kind of ridiculous, right? This makes it really easy 00:06:51.200 --> 00:06:55.440 to automate that across the board, all right, and tell you what's in compliance, what's not, 00:06:55.440 --> 00:07:00.320 and then to push it all to be in compliance. Hardware verification, again, make sure your 00:07:00.320 --> 00:07:05.839 hardware is on the hardware compatibility guide. vSAN has a different hardware compatibility list 00:07:05.839 --> 00:07:11.920 than the operating system does, right? You can say ESXi in general has this hardware compatibility list, 00:07:11.920 --> 00:07:16.239 but if you want to run vSAN, there's other components that also need to make sure you have, 00:07:16.239 --> 00:07:21.279 you know, compatible for vSAN to be compatible with. If you're not running vSAN, those items 00:07:21.279 --> 00:07:25.519 don't need to be checked. If you're running vSAN, you need to make sure you've got a controller 00:07:26.720 --> 00:07:30.640 that is, you know, on the compatibility list for vSAN and some things like that. 00:07:30.640 --> 00:07:37.040 And so, what I mean by that is, this is just one example, RAID controllers, right? vSAN does not 00:07:37.040 --> 00:07:44.399 want this presented as a big, single RAID array. It doesn't want you taking your 15 disks in this 00:07:44.399 --> 00:07:51.839 host and creating a RAID anything, not a RAID 0, not a RAID 1, not a RAID 5 or 6. It wants you just 00:07:51.839 --> 00:07:59.679 to present all the disks as just raw disks. So, RAID controllers now that are designed to work 00:07:59.679 --> 00:08:05.839 with vSAN, if they can do RAID, they can do a RAID 0, RAID 5, or RAID 6, or RAID 10, whatever 00:08:05.839 --> 00:08:10.640 you want. So, you can install another operating system and use that RAID controller, or they can 00:08:10.640 --> 00:08:15.359 also just be into like a physical compatibility mode where they just present the disks, right? 00:08:15.359 --> 00:08:21.600 They are not doing any kind of RAID controller at all. They're just presenting the disks to the 00:08:21.600 --> 00:08:29.200 operating system. And then ESXi will see 15 disks, and then vSAN can treat those 15 disks how it 00:08:29.200 --> 00:08:33.520 wants. It can create their pools with the disks and things like that and put VMs on disks the 00:08:33.520 --> 00:08:39.919 way that vSAN wants to run vSAN. So, that's an example of, you know, an older RAID controller 00:08:39.919 --> 00:08:44.719 wouldn't have that functionality that vSAN needs. And so, make sure your RAID controller is 00:08:44.719 --> 00:08:49.919 compatible with vSAN. ESXi may not care about that at all if you're not running vSAN, right? 00:08:49.919 --> 00:08:54.400 So, a RAID controller that can't do that is compatible with ESXi, but it's not compatible 00:08:54.400 --> 00:08:59.520 with ESXi running vSAN. Just kind of keep that in mind. Make sure that you know if you're running 00:08:59.520 --> 00:09:04.960 vSAN that you need to do additional checks other than just the ESXi hardware compatibility list. 00:09:05.599 --> 00:09:11.359 So, here we're seeing we have a bunch of hosts, right? And our hosts are all running an older 00:09:11.359 --> 00:09:16.239 image. We have our golden image, and then we have all these old images. And they may be the same 00:09:16.239 --> 00:09:20.719 as an older golden image, or they could all be different. I could have four different 00:09:20.719 --> 00:09:25.200 configurations, four different images, four different, you know, sets of, you know, drivers 00:09:25.200 --> 00:09:30.159 and things like that out there. And I want to get it all the same. I want all my hosts patched to 00:09:30.640 --> 00:09:36.239 the same level, running the same version of ESXi, with the same drivers, all the same bibs, 00:09:36.239 --> 00:09:40.400 all the everything, right? So, we can go and we can create that golden image. 00:09:41.840 --> 00:09:45.440 We can say we want to sync the golden image with the host. So, the first thing you're going to do 00:09:45.440 --> 00:09:50.159 is you're going to go there and just tell it to compare and tell me in a report which ones are 00:09:50.159 --> 00:09:54.080 in compliance and which ones aren't, and maybe none of them are. Then we can tell it we want 00:09:54.080 --> 00:09:59.200 to remediate that. We want it to go through, and we want to make them all match. So, we can 00:09:59.200 --> 00:10:05.119 make them all match. And it will go through each one. It'll evacuate the host. It'll put it in 00:10:05.119 --> 00:10:09.359 maintenance mode. It'll push out the drivers and do, you know, all that kind of updating. 00:10:10.000 --> 00:10:13.760 And then it's going to reboot it, and then it's going to come back up again, and it'll take it 00:10:13.760 --> 00:10:17.840 out of maintenance mode. And you can tell it to do the whole cluster, and it'll go through one 00:10:17.840 --> 00:10:24.640 at a time and do that. Many times, I'm a little bit, you know, gun shy about doing that because 00:10:24.640 --> 00:10:30.239 I don't want the system to think everything's great, and it has happened before where I updated 00:10:30.239 --> 00:10:37.039 a host, and vCenter said everything was fine, and the VMs on that host were just not running well. 00:10:37.039 --> 00:10:42.000 They were running. They were running poorly. There was all kinds of, you know, performance issues, 00:10:42.000 --> 00:10:47.520 and I had to evacuate the VMs off that host, reboot again, and then it came up fine, right? 00:10:47.520 --> 00:10:50.559 I've also had upgrades that just went sideways, and the host wouldn't come back up again. But 00:10:50.559 --> 00:10:55.840 vCenter would know that, and it wouldn't put VMs on there. Sometimes, there's problems that vCenter 00:10:55.840 --> 00:11:01.599 doesn't know about, and it starts putting VMs back on hosts. So, I like to kind of do one-by-one 00:11:01.599 --> 00:11:05.919 myself and kind of keep an eye on it. I've been in environments, though, where that's just not 00:11:05.919 --> 00:11:10.799 practical. I've been in environments where, you know, there's just dozens and dozens and dozens 00:11:10.799 --> 00:11:17.520 of hosts, and we don't have time to sit and babysit each one. And so, we'll just go into a 00:11:17.520 --> 00:11:21.919 cluster, do a cluster, monitor, make sure everything's okay, make sure all the things 00:11:21.919 --> 00:11:27.200 are performing well before we let it do the next cluster. That's just been my experience. So, 00:11:27.919 --> 00:11:33.200 most of the time, 99% of the time, upgrades go without a hitch. But that one time that it doesn't, 00:11:33.200 --> 00:11:39.280 that you get phone calls and people are upset. So, just be a little bit cautious, but I would 00:11:39.280 --> 00:11:44.080 definitely trust the process. I've had good luck with it across, you know, in general, with few 00:11:44.080 --> 00:11:51.599 exceptions. So, using the Lifecycle Manager, we can define a golden image, right? We can use a 00:11:51.599 --> 00:11:58.479 host to go in and be our base image for that. We can select the ESXi version we want to be our base. 00:11:58.479 --> 00:12:02.799 We can also add to an image things like vendors, like vendor add-ons. We can say, 00:12:02.799 --> 00:12:08.719 these are Dell servers. These are Dell R, you know, 810s and this and that and that kind of thing. 00:12:08.719 --> 00:12:12.960 And we need to have this compatible with that, with that image. And it'll get all the right 00:12:12.960 --> 00:12:17.840 drivers for our vendor and all that stuff and make that part of our base image for us, okay? 00:12:18.400 --> 00:12:22.719 After we've gone through and we've created that image, then we want to go through and check our 00:12:22.719 --> 00:12:27.359 cluster, right? We want to check our cluster and make sure that it's in compliance with our image. 00:12:27.359 --> 00:12:32.000 And when it's a brand new image, it obviously won't be, right? If it's not in compliance, 00:12:32.000 --> 00:12:36.320 then Lifecycle Manager can go through, show us which ones are, which ones are not. And then we 00:12:36.320 --> 00:12:41.359 can say to remediate. And again, that remediation means putting the host in maintenance mode, 00:12:41.359 --> 00:12:45.280 patching, rebooting, taking it out of maintenance mode. And then a service like 00:12:45.280 --> 00:12:48.000 DRS could go in and start putting VMSec on there for us. 00:12:51.919 --> 00:12:56.239 So, finishing the image setup. So, once we've gone through, we can save it to our cluster. 00:12:56.239 --> 00:13:00.479 And we'll see that you can, you know, that, yeah, you can have an image attached to a cluster. 00:13:01.679 --> 00:13:05.840 Go and remediate. If there are issues, you can do remediation. After you do your remediation, 00:13:05.840 --> 00:13:11.679 then run the check again just to make sure that everything did apply. You could also check each 00:13:11.679 --> 00:13:16.080 host as it's going along and go into the logs and check the logs. You can go to the host. 00:13:16.080 --> 00:13:20.880 And at the host level, you can say remediate or check just this host. And is this host now 00:13:20.880 --> 00:13:27.200 in compliance? You can do it that way as well. Here we can say you can export an image. So, 00:13:27.200 --> 00:13:31.679 why would you want to export an image? Well, you might want to export an image because you've got 00:13:31.679 --> 00:13:36.159 this vCenter, you know, image exactly the way you want. Maybe it took you hours to get it just 00:13:36.159 --> 00:13:40.960 the way you needed it. Now you can export it, take it to another vCenter server. You can bring it in 00:13:40.960 --> 00:13:48.239 there. And you can, you know, now apply that and reuse all that work you did in the first vCenter 00:13:48.239 --> 00:13:53.039 and subsequent vCenters that are running the same hardware that you want patched the same level. 00:13:53.039 --> 00:13:58.239 So, maybe we did this in our lab and our lab's tuned perfectly and we want to bring it into 00:13:58.239 --> 00:14:04.239 production. Or we, you know, tuned it in a lab and now we've got 10 different production 00:14:04.239 --> 00:14:08.239 environments we need to push it out to, that kind of thing. So, it's nice being able to export that 00:14:08.239 --> 00:14:15.440 image and use it again somewhere else. So, host compatibility, verify the host 00:14:15.440 --> 00:14:21.840 compatibility. You're going to use the host compatibility list. You also want to use the 00:14:21.840 --> 00:14:26.159 vSAN hardware compatibility list like I mentioned, right? So, you want to use the hardware compatibility 00:14:26.159 --> 00:14:30.880 guide or the VMware compatibility guide. And you want to use the vSAN hardware compatibility 00:14:30.880 --> 00:14:36.880 list. And we discussed just a moment ago, you know, why they might be different. Run a compatibility 00:14:36.880 --> 00:14:41.440 check. So, you can run this check beforehand. You'll see in our lab where we have these 00:14:41.440 --> 00:14:46.080 ESXi hosts, our virtual machines, we're going to get a message that our processors aren't 00:14:46.080 --> 00:14:51.760 compatible. We can still move forward. It won't be a problem for doing the demo. But you'll see 00:14:51.760 --> 00:14:55.520 that it does check and make sure and says, oh, you know, you've got a problem with, you know, 00:14:55.520 --> 00:15:01.119 the CPU. There's a problem with the HBA or something like that. You can sync your updates. 00:15:01.119 --> 00:15:07.440 You can stage your updates, meaning that the system, the vCenter can actually push the updates 00:15:07.440 --> 00:15:11.679 out to the host. They're staged there. But they're not going to be installed until you say you want 00:15:11.679 --> 00:15:16.320 to actually remediate. And that way, if you wanted to say, okay, we're going to do this tonight and 00:15:16.320 --> 00:15:21.599 we want to go as quick as we can, it's still going to take time. But you can save the time of copying 00:15:21.599 --> 00:15:27.840 updates to the host and do that earlier during the day by staging them first. Okay. And then you 00:15:27.840 --> 00:15:31.440 can say if you want, if you're going to, you know, sync with the HCL or not. Okay. 00:15:34.080 --> 00:15:40.960 So, upgrades suite for electrical manager. So, we can push out entire updates. Rather than just 00:15:40.960 --> 00:15:45.840 doing patches and that, you know, saying, okay, here's a new security update available for our 00:15:45.840 --> 00:15:51.280 ESXi host, we can say we want to actually do a full operating system. So, if we're running on 00:15:52.000 --> 00:15:57.200 8.0, you know, update one, we want to go to 8.03 or something like that. Right. Download the ISO. 00:15:57.840 --> 00:16:03.760 And then we can go through. We can say we want to upgrade. Man, oh, here's with vRealize. We can use 00:16:03.760 --> 00:16:08.799 vRealize. So, that's what the whole lifecycle manager suite part is about, is that we're pushing 00:16:08.799 --> 00:16:14.799 that through vRealize. Okay. So, vRealize, basically, it's just an automation tool to where 00:16:14.799 --> 00:16:19.599 I don't have to go to each cluster and the vCenter and things like that. vRealize allows me to do 00:16:19.599 --> 00:16:24.400 pretty much all the same checks that we would normally do, but we can do them on a bigger scale, 00:16:24.960 --> 00:16:29.919 attach to multiple vCenter servers, and we can automate this, you know, pushing the things out, 00:16:29.919 --> 00:16:34.320 pushing the images out to multiple vCenters and clusters and things like that all at the same 00:16:34.320 --> 00:16:40.719 time. So, and we can upgrade our system using vRealize and the upgrade suite lifecycle manager 00:16:40.719 --> 00:16:45.520 that's in vRealize. All right. So, again, all the same things. You can check if the upgrade's needed, 00:16:45.520 --> 00:16:50.719 select what version you want to be on. It's going to find the ISO, say, yep, here's the ISO 00:16:50.719 --> 00:16:54.559 we're going to use to push this out to the host, and then you can go through and you can start your 00:16:54.559 --> 00:17:02.000 patching. So, some known issues when you're upgrading. So, if you're upgrading vCenter 00:17:02.000 --> 00:17:07.599 and using lifecycle manager, you might need to go in and reset the lifecycle manager database. 00:17:07.599 --> 00:17:11.119 We discussed this when we talked about upgrading vCenter before, too. If we're going from, like, 00:17:11.119 --> 00:17:17.199 version 7 to version 8, lifecycle manager might kind of hiccup on you during that upgrade. So, 00:17:17.199 --> 00:17:22.800 all we need to do is connect to the vCenter server shells or an SSH into the vCenter server, 00:17:22.800 --> 00:17:28.640 and we're going to stop the update manager service. We are going to basically go in and 00:17:29.439 --> 00:17:35.280 run a command to reset the database. Then we're going to delete all the patches that are in the 00:17:35.280 --> 00:17:41.199 patch folder for the update manager, and then we're going to restart the update manager service. 00:17:41.199 --> 00:17:44.959 And when we restart the update manager service, it's going to check in with VMware's website again, 00:17:44.959 --> 00:17:50.160 download all the updates, rebuild that database, and then we can say, okay, now we got this all 00:17:50.160 --> 00:17:54.479 rebuilt. This is the patch level that we are configured for, and we can start, you know, 00:17:54.479 --> 00:17:57.280 updating and pushing things out again after we've updated vCenter. 00:17:59.359 --> 00:18:04.239 So, we discussed lifecycle manager. We discussed some improvements to lifecycle manager. 00:18:04.239 --> 00:18:09.599 We discussed using lifecycle manager for patching and upgrading. We discussed host 00:18:09.599 --> 00:18:13.760 compatibility. You want to make sure that the various components on your host are compatible 00:18:13.760 --> 00:18:20.000 with lifecycle manager with ESXi specifically, and also if you're using vSAN, compatible with vSAN. 00:18:20.000 --> 00:18:25.520 And we discussed a known issue known with upgrading your vCenter server and lifecycle manager.