WEBVTT 00:00:00.000 --> 00:00:03.680 Welcome back to vSphere 8 in the real world. Now we're going to discuss an introduction to vSphere. 00:00:06.320 --> 00:00:13.760 So what is vSphere? So vSphere is not really a single product. It's a suite of products. So it's 00:00:13.760 --> 00:00:19.040 kind of like talk about Microsoft Office, right? We have Word, we have Excel, we have PowerPoint, 00:00:19.040 --> 00:00:22.959 we have OneNote. There's all these different applications, all these different products, 00:00:22.959 --> 00:00:28.320 and then Microsoft has grouped them together into a suite that they call Microsoft Office. 00:00:28.320 --> 00:00:33.200 So vSphere is kind of the same way. So with vSphere, we have ESXi, right? And that's kind 00:00:33.200 --> 00:00:38.639 of the core, the foundation, that's like the basic piece you have to have to have a vSphere 00:00:38.639 --> 00:00:42.639 environment. But if you want to manage that vSphere environment, which without management, 00:00:42.639 --> 00:00:46.639 you don't have a vSphere environment, you also need vCenter, right? So there's at least two 00:00:46.639 --> 00:00:50.400 products you're going to have to have to have vSphere. You're going to have to have ESXi, 00:00:50.400 --> 00:00:54.720 and you're going to have to have vCenter. Now, as I mentioned in previous lessons, 00:00:55.360 --> 00:01:00.480 you might also have Horizon for virtual desktops. You might also go, you know, 00:01:00.480 --> 00:01:04.480 real advanced in your networking and go to software-defined networking and use NSX. 00:01:04.480 --> 00:01:10.400 You might add other tools in for Kubernetes for, you know, for doing containers. You might also do, 00:01:12.480 --> 00:01:16.480 you know, advanced reporting and things like that with vRealize. So there's a lot of different 00:01:16.480 --> 00:01:22.959 things that VMware sells that you can plug into, you know, your vCenter and work with your ESXi. 00:01:22.959 --> 00:01:27.040 But the foundation, the most basic components that you're going to have to have to have a vSphere 00:01:27.040 --> 00:01:33.519 environment, ESXi, the hypervisor, and vCenter, the management tool for the hypervisor. And then 00:01:33.519 --> 00:01:38.559 there's a bunch of other things you can plug in on top of that to enhance that experience to make 00:01:38.559 --> 00:01:45.599 your data center more robust, okay? So for managing this vSphere environment, 00:01:45.599 --> 00:01:49.599 you have a lot of different options. The most common one, usually one of the very first ones 00:01:49.599 --> 00:01:54.720 most people use after the DCUI, because you'll probably go into DCUI on your ESXi host and 00:01:54.720 --> 00:02:00.080 assign it an IP address and things like that. But then it's the web client. You're going to connect 00:02:00.080 --> 00:02:05.519 to your host through the web client, or you might connect to vCenter through the web client and add 00:02:05.519 --> 00:02:10.639 your host in. It kind of, you know, it's up to you. But the web client is where you're going to do a 00:02:10.639 --> 00:02:14.240 lot of your management in your vSphere environment. That's where people spend most of their time. 00:02:14.240 --> 00:02:17.440 If you want to look at performance, you know, of your vSphere environment, you're probably going to 00:02:17.440 --> 00:02:22.399 go to the web client or vCenter and look at performance. If you want to create a data store, 00:02:22.399 --> 00:02:26.720 if you want to add another host, you want to create a new VM. Now, you don't have to do all 00:02:26.720 --> 00:02:31.520 those things for the web client. You can also do a lot of these things from a command line. 00:02:31.520 --> 00:02:36.399 You can go into either the DCUI, meaning like, you know, the console of that machine, 00:02:36.399 --> 00:02:40.399 or you can connect to the host or vCenter through SSH and manage them that way. 00:02:41.759 --> 00:02:45.600 If you have, you can do a lot of scripting, you want to automate a lot of tasks and things like 00:02:45.600 --> 00:02:49.119 that, that might be how you do it. You might, you know, create scripts and, you know, the automate 00:02:49.119 --> 00:02:55.839 tasks that you do a lot and connect through SSH and run your scripts. Most people spend a lot of 00:02:55.839 --> 00:03:00.960 their time actually in vCenter. And that, you know, that would be done through that web client. 00:03:04.240 --> 00:03:09.679 So, objects that you're going to see in your web client, objects that you're going to manage 00:03:09.759 --> 00:03:15.600 in your vSphere environment will be the VMs, obviously, right? The first thing, first and 00:03:15.600 --> 00:03:19.199 foremost, will be your hosts. You're going to configure your virtual networking, you're going 00:03:19.199 --> 00:03:22.399 to configure your storage, you're going to configure, you know, all that kind of stuff to 00:03:22.399 --> 00:03:27.360 get the host ready for virtual machines. Then you start creating VMs. And that's the whole point. 00:03:27.360 --> 00:03:31.279 That's why you have vSphere. You have vSphere because you want to, you know, run virtual 00:03:31.279 --> 00:03:35.759 machines, you want to run workloads, you want to get work done. What gets that work done are your 00:03:35.759 --> 00:03:41.279 VMs and those VMs live on your hosts, okay? Now, there's data centers too. And data centers 00:03:41.279 --> 00:03:45.199 are kind of what they sound like. A lot of times your data center might be, if you have a data 00:03:45.199 --> 00:03:50.080 center in Houston, you might have a Houston data center in your vSphere environment. And if you 00:03:50.080 --> 00:03:55.440 have another data center in, you know, San Francisco or New York or Seattle, you might 00:03:55.440 --> 00:04:01.520 have data centers listed like that. Now, they don't necessarily have to be that way, right? 00:04:01.520 --> 00:04:05.759 You can kind of call them whatever you want. They don't have to be geographically, 00:04:05.759 --> 00:04:11.520 you know, divided or organized in vCenter. This is a really common way that most people kind 00:04:11.520 --> 00:04:17.200 of organize and group their resources. Maybe you have some huge infrastructure with this 00:04:17.200 --> 00:04:21.839 massive backbone and to use San Francisco and Houston are the same thing. I can easily move 00:04:21.839 --> 00:04:28.320 a VM from a server in Dallas over to San Francisco, no problem, because I have this huge 00:04:28.320 --> 00:04:33.040 pipe between them and they just kind of live like they're one environment, okay? That's really 00:04:33.040 --> 00:04:40.720 uncommon. That's not the most likely scenario for 99% of the people out there. So, if that is you, 00:04:40.720 --> 00:04:44.559 then you may not have a San Francisco data center and a Houston data center. You might, 00:04:44.559 --> 00:04:50.079 you know, have some other name for it that, you know, is more business oriented, 00:04:50.079 --> 00:04:54.079 business function oriented or something like that. Most people are going to have their Houston and 00:04:54.079 --> 00:04:58.239 their San Francisco and their New York and their LA and things like that. And then within that 00:04:58.239 --> 00:05:06.320 data center, I can start creating clusters. If I only have five hosts or 10 hosts in my data center 00:05:06.320 --> 00:05:13.600 in Dallas or Houston or whatever, then maybe I just have one cluster. But maybe I have a couple 00:05:13.600 --> 00:05:19.040 of hundred hosts in my, you know, Dallas data center. And so, I have a cluster that is for 00:05:19.040 --> 00:05:23.440 this group of hosts that run these kinds of workloads. And I have another cluster that's 00:05:23.440 --> 00:05:27.760 for another group of hosts that runs a different type of workload. Another reason why you might 00:05:27.760 --> 00:05:34.000 create multiple clusters would be these hosts here are three years old. They have a certain 00:05:34.000 --> 00:05:38.959 generation of Intel processor and certain resources, your hardware in them. And this 00:05:38.959 --> 00:05:46.320 other cluster that we just got last week has the most latest, greatest Intel generation processors. 00:05:46.320 --> 00:05:52.559 Well, vMotion isn't going to work from hosts in this cluster to this one unless I turn on what 00:05:52.559 --> 00:05:57.279 they call enhanced vMotion capabilities. And then basically, I'm dumbing down the processor. I just 00:05:57.279 --> 00:06:02.160 paid a bunch of money for. And I don't want to do that. In this scenario, for this example, 00:06:02.160 --> 00:06:08.079 I don't want to dumb down my processors and not let my VM use all the new advanced features of 00:06:08.079 --> 00:06:14.000 this processor. So, I'm going to create a cluster for my newest hosts. And so, the VMs can move 00:06:14.000 --> 00:06:18.799 around all these hosts, no problem, because they all have the same processor. And this other cluster 00:06:18.799 --> 00:06:23.359 has, you know, a slightly older generation of Intel processor. And so, they can move around 00:06:23.359 --> 00:06:27.040 them, no problem, because they're all the same. But they can't go back and forth very easily. 00:06:27.040 --> 00:06:32.079 And I might have a third cluster that's running AMD processors. And so, therefore, 00:06:32.079 --> 00:06:37.839 I need to have those divided up separately too. So, that's just, you know, one reason why you 00:06:37.839 --> 00:06:41.839 might create multiple clusters. The number of hosts you have might be multiple clusters. The 00:06:41.839 --> 00:06:46.399 types of workloads you want to run on these clusters. I want this cluster to just be for 00:06:46.399 --> 00:06:51.200 a certain type of workload. So, I create a cluster for that. All right. So, clusters are just groups 00:06:51.200 --> 00:06:56.959 of hosts. And you can group them for various different reasons. Then a resource pool is a way 00:06:56.959 --> 00:07:03.200 of carving up that cluster to say that the VMs that I put in this resource pool either are going 00:07:03.200 --> 00:07:07.600 to be limited and only able to use a certain amount of resource, or they're going to be 00:07:07.600 --> 00:07:12.880 guaranteed through a reservation a certain amount of resource, right? So, maybe in this resource pool, 00:07:12.880 --> 00:07:20.239 I have, you know, a few VMs that are a very critical, high-priority workload. And I want 00:07:20.239 --> 00:07:24.640 to make sure they're guaranteed at least certain resources. So, I put a reservation on the resource 00:07:24.640 --> 00:07:30.640 pool, put the VMs in there. These VMs are always going to have at least minimum the resources 00:07:30.640 --> 00:07:34.880 guaranteed on that resource pool. Maybe you have another resource pool, and these VMs are the 00:07:34.880 --> 00:07:41.119 complete opposite. I want them to run. I need their work done. But if it gets done right away, 00:07:41.119 --> 00:07:47.359 or if it takes them 20, 30, 40 minutes, or whatever, I don't care. So, I'm going to put 00:07:47.440 --> 00:07:52.559 limits on this resource pool. So, these VMs are going to run and get their work done, 00:07:52.559 --> 00:07:56.880 but it might take them a while because they can't use all the resources that are available. 00:07:56.880 --> 00:08:00.399 They can't use all the resources that are available to the first resource pool that ran my 00:08:00.399 --> 00:08:05.040 priority workload, right? They have that reservation set to it. So, resource pools can be used for 00:08:05.040 --> 00:08:12.320 different reasons. You do see resource pools used for sure, but not as much as you might think 00:08:12.320 --> 00:08:15.920 because they can get tricky. Because I can have a resource pool within a resource pool. 00:08:15.920 --> 00:08:21.279 I can have my cluster, which your cluster is kind of without being called this a resource pool. 00:08:21.839 --> 00:08:27.519 Then within this cluster, I can create another resource pool, and I can guarantee it a certain 00:08:27.519 --> 00:08:35.039 amount of resources. I can then create a resource pool within that and guarantee this another amount 00:08:35.039 --> 00:08:40.239 of resources. But this resource that's guaranteed can't exceed what the one above it's guaranteed 00:08:40.239 --> 00:08:44.960 because it has to feed off of that percentage of that. We'll get into resource pools and stuff 00:08:44.960 --> 00:08:52.239 more. Just realize that they're very useful. They are definitely used, but they're not used 00:08:52.239 --> 00:08:57.440 just willy-nilly, not just kind of thrown around. Not everything lives in a resource pool, 00:08:57.440 --> 00:09:03.359 okay, because they can get a little bit tricky. Use them when appropriate, but don't abuse them. 00:09:05.599 --> 00:09:11.280 So, plugins. So, with vSphere 8, they actually, plugins used to be installed into your vCenter 00:09:11.280 --> 00:09:14.960 server, right? And they're kind of managed through there. When you logged in, you would 00:09:14.960 --> 00:09:20.799 see the plugin. Now, we have what we call remote plugins. And so, the plugins no longer live 00:09:21.520 --> 00:09:26.559 in vCenter. They live outside of vCenter. They live with the host and with your browsers and 00:09:26.559 --> 00:09:31.760 stuff. And so, it's a much more secure model. It makes it kind of easier for managing plugins. 00:09:33.119 --> 00:09:38.400 And for the time being, your local plugins might still work, but they might not. So, 00:09:39.119 --> 00:09:44.000 make sure before you upgrade to vSphere 8 that you know, are you using plugins or not? And is 00:09:44.000 --> 00:09:48.799 there a new remote plugin to replace the one you're currently using from your vendor? Because 00:09:48.799 --> 00:09:52.080 if not, whatever you're using that plugin for might not work with vSphere 8. 00:09:55.200 --> 00:09:58.479 So, some goals of virtualization. So, first of all, hardware independence. 00:09:59.919 --> 00:10:08.000 I no longer have to worry that my VM has to run on this certain generation Intel processor 00:10:08.000 --> 00:10:14.719 and this network card and this motherboard and things like that. It's going to use a VMware 00:10:14.719 --> 00:10:20.719 driver for a network card, a VMware driver for the video display, and everything's going to 00:10:20.719 --> 00:10:25.359 be virtualized. The only thing that really the VM sees directly that it knows it has 00:10:26.080 --> 00:10:30.640 is that processor. But if I shut down the VM and move it to a different host with a different 00:10:30.640 --> 00:10:36.960 processor, the VM should still run no problem. The only issue would be trying to live migrate 00:10:36.960 --> 00:10:41.599 it from one host to another. The processors can't be different. They need to be the same family, 00:10:41.599 --> 00:10:47.760 same generation of processors. But what that means is that this VM running on this host over here, 00:10:47.760 --> 00:10:52.080 all of a sudden, this host catches fire. I can just start it up on those hosts over there. 00:10:52.080 --> 00:10:57.039 And maybe those hosts have newer processors, older processors, different vendor processors. 00:10:57.039 --> 00:11:00.479 It doesn't matter. I don't have to worry about what network cards over there. I don't have to 00:11:00.479 --> 00:11:04.559 worry about what hard drives over there, what motherboard, what BIOS is on that motherboard, 00:11:04.960 --> 00:11:09.679 devices are attached to the motherboard. None of that's going to matter. The VM is going to 00:11:09.679 --> 00:11:14.719 see the same set of drivers it saw before because it's all just virtualized, right? 00:11:14.719 --> 00:11:20.080 There's that abstraction of the hardware from the physical machine to the virtual machine, 00:11:20.080 --> 00:11:26.719 and the hypervisor in the middle there abstracts that out. So efficiency, like I mentioned before, 00:11:26.719 --> 00:11:32.719 in a physical environment, when we had all physical data centers, it was very common to see 00:11:32.719 --> 00:11:37.679 people do reports on data center utilization and find out, yeah, we're running hundreds of servers, 00:11:37.679 --> 00:11:43.280 and we are running below 10% utilization on average across this whole data center. 00:11:43.280 --> 00:11:48.960 We're wasting a ton of money on hardware, a ton of money on electricity, a ton of money on cooling 00:11:48.960 --> 00:11:56.239 of those machines because I have to isolate this application from that application, and this 00:11:56.239 --> 00:12:01.760 service from that service, and things like that. So with virtualization, I can take all these VMs, 00:12:01.760 --> 00:12:06.880 these applications that are isolated from each other in VMs, and stack them on top of each other 00:12:06.880 --> 00:12:13.359 in this host, and none of them see each other. Now my host went from 6% or 7% utilized to 75% 00:12:13.359 --> 00:12:20.159 utilized. So what that now means, I don't need 300 hosts. I only need 65 hosts or something like that 00:12:20.159 --> 00:12:26.400 maybe, right? I can get by with far fewer. That means less electricity, less cooling, less square 00:12:26.400 --> 00:12:32.880 footage in my data center, all that kind of stuff. So flexibility, again, I can easily move VMs from 00:12:32.880 --> 00:12:37.440 one host to another. If I want to patch this physical host over here, I can just move the VMs 00:12:37.440 --> 00:12:41.679 off onto another host. They're still running. No one ever knows they moved. I can patch the host, 00:12:41.679 --> 00:12:46.479 move things around. If I need to upgrade hardware, I need to add more RAM to the host. I need to add 00:12:46.479 --> 00:12:50.640 more network cards, upgrade the network cards. I need to take out these one gig NICs and put in 10 00:12:50.640 --> 00:12:55.039 gig NICs because the network's running too slow. The VMs don't know. They don't care. When they 00:12:55.039 --> 00:13:00.159 get back on the host with a new 10 gig NICs, they see the same network interface card. They just keep 00:13:00.159 --> 00:13:04.640 running and doing their thing. It's no problem at all. Resource allocation, we've talked about 00:13:04.640 --> 00:13:08.640 resource pools and things like that. We can create reservations. We can then use shares. 00:13:08.640 --> 00:13:13.599 We can allocate a certain number of virtual CPUs to a VM, a certain amount of RAM to a VM. 00:13:13.599 --> 00:13:19.200 We can add RAM. We can add virtual CPUs to the VM. We don't have to worry about, in the old days, 00:13:19.200 --> 00:13:24.239 when we bought a host, we bought the biggest host our budget would allow us. Did I need all that? 00:13:24.239 --> 00:13:29.840 I don't know. Maybe not. But I have the budget today. And if I don't spend the money today, 00:13:29.840 --> 00:13:33.840 and all of a sudden, next year, I need more RAM, I may not have the budget for it. I may not get that. 00:13:34.400 --> 00:13:39.760 In a virtual environment, you want to give your VMs the minimum hardware they need to do their 00:13:39.760 --> 00:13:44.960 job. So maybe I'll create a VM and only give it two virtual CPUs, and I'll give it four or six 00:13:44.960 --> 00:13:49.119 gigs of RAM. And it runs fine. All of a sudden, next year, it's not running so well. All of a 00:13:49.119 --> 00:13:54.640 sudden, it needs more RAM. Adding RAM, it's a matter of checking a little arrow, bumping up 00:13:54.640 --> 00:14:00.159 the RAM. I need to add more virtual CPUs. No problem. Add more virtual CPUs. I don't have to 00:14:00.159 --> 00:14:04.320 go out and ask for more budget to buy this. They're already in the box. I bought the biggest 00:14:04.320 --> 00:14:11.599 box I can afford budget-wise. But now, I only allocate what VMs need. I'm not wasting resources 00:14:11.599 --> 00:14:15.280 that way. So you can allocate resources in a very detailed, methodical way. 00:14:16.239 --> 00:14:22.000 DR and business continuity plans. So there's all kinds of different solutions out there now to 00:14:22.000 --> 00:14:27.440 where I can be running my data center, and everything in this data center, maybe I'm running 00:14:27.440 --> 00:14:31.280 hundreds of virtual machines, thousands of virtual machines on hundreds of hosts or something like 00:14:31.280 --> 00:14:38.000 that. And everything's being copied over to another data center in a different city or state or 00:14:38.000 --> 00:14:44.159 country. And all of a sudden, something happens, and this data center catches fire, it burns down, 00:14:44.239 --> 00:14:49.679 a tornado takes it out. There's a massive power outage that's not going to be fixed for days and 00:14:49.679 --> 00:14:56.880 days and days. And my generators can't run that long. ISP issues. Someone hit the side of the 00:14:56.880 --> 00:15:01.840 building with a truck and took out all the ISPs that were coming into the building. I just fail 00:15:01.840 --> 00:15:07.679 over to this other data center over here, and all the VMs come up. And maybe I had some downtime. 00:15:07.679 --> 00:15:12.960 Maybe I had downtime of 10, 15, 20 minutes. Maybe I didn't have any at all. I planned it. I said, 00:15:12.960 --> 00:15:17.679 oh, wow, there's a huge storm coming, and pretty likely we're going to lose power to this building 00:15:17.679 --> 00:15:23.039 for quite a while. And our generators, I know, only run for eight hours before we're out of fuel, 00:15:23.039 --> 00:15:27.119 and we won't get more fuel. I'm just going to fail everything over to this data center over in this 00:15:27.119 --> 00:15:32.080 other city, this other state that won't be impacted by the storm. So, I just DR everything over, 00:15:32.080 --> 00:15:35.679 right? I planned for this failure to happen. I don't have to sit there and sweat and worry 00:15:35.679 --> 00:15:39.440 what happens if this goes down. How am I going to get these resources up and running? 00:15:40.400 --> 00:15:46.320 I can do it by checking a couple boxes in an application. So, my DR, my business continuity 00:15:46.320 --> 00:15:52.080 plans become very flexible, very dynamic, really easy to implement. There's all kinds 00:15:52.080 --> 00:15:59.039 of solutions out there to help me do that. So, advantages and disadvantages of virtualization. 00:15:59.039 --> 00:16:03.679 So, some advantages, shared resources, right? A bunch of VMs running on one host, 00:16:03.679 --> 00:16:07.200 taking advantage of all these resources that I paid a bunch of money. I paid a bunch of money 00:16:07.200 --> 00:16:12.559 for all this RAM. I paid a bunch of money for these super fast processors. And with virtualization, 00:16:12.559 --> 00:16:16.479 I'm taking advantage of all these resources with all these different services on these 00:16:16.479 --> 00:16:21.919 different virtual machines using them up, okay? Business continuity solutions, like we just 00:16:21.919 --> 00:16:28.400 described, become very simple, much easier to plan, much easier to implement, much easier to 00:16:28.400 --> 00:16:33.280 execute, all that kind of stuff. Flexibility from hardware. I don't have to worry about, 00:16:33.440 --> 00:16:38.719 you know, buying more servers and getting the exact same Dell server with the same motherboard 00:16:38.719 --> 00:16:44.880 and the same NICs and the same processors. I'll be like, oh, a year later, I need more servers. 00:16:44.880 --> 00:16:49.760 Great. Give me the fastest processor. Give me the greatest, latest, greatest, you know, chip set on 00:16:49.760 --> 00:16:53.520 the network cards and all that, and we're going to roll this out. And we'll create a new cluster 00:16:53.520 --> 00:16:58.320 for these guys and move some VMs over there. No problem. Everything's good, right? Downtime for, 00:16:58.320 --> 00:17:01.039 you know, maintenance for patching and things like that becomes very easy. 00:17:01.039 --> 00:17:05.119 So, some disadvantages. Isn't that kind of funny? The first advantage is shared resources, 00:17:05.119 --> 00:17:10.000 and the first disadvantage is also shared resources. The disadvantage of shared resources, 00:17:10.000 --> 00:17:16.479 it could be that if you haven't used things like shares, if you haven't used things like 00:17:16.479 --> 00:17:22.479 reservations, that certain VMs can start to monopolize a host. Certain VMs, you might allocate, 00:17:22.479 --> 00:17:27.119 you know, more resources to, more virtual processors or something like that, and all of a sudden, 00:17:27.119 --> 00:17:32.880 other VMs are being impacted. It's what they call a noisy neighbor. One neighbor is just more 00:17:32.880 --> 00:17:37.680 demanding for resources, and the hypervisor's trying to be fair and dish things out, but based 00:17:37.680 --> 00:17:42.479 upon how you configured things, this guy is getting a lot more than the other ones, and it's choking 00:17:42.479 --> 00:17:48.560 those ones out. You can fix that. Obviously, you can implement shares. You can implement 00:17:48.560 --> 00:17:52.560 reservations and things like that, but it's something you need to keep in mind. It could 00:17:52.719 --> 00:17:56.239 become a problem if you don't think about it and plan it out in advance. 00:17:57.280 --> 00:18:02.079 So, host failures lead to multiple VM failures. In a physical environment, if a host burns down, 00:18:02.959 --> 00:18:07.760 you lost a service. You might have lost a domain controller. You might have lost a DHCP server or 00:18:07.760 --> 00:18:13.839 something like that. In a virtual environment, if a host burns down, I might have lost 30 VMs. I 00:18:13.839 --> 00:18:18.160 might have lost a domain controller and a DHCP server and a SQL server and an Exchange server 00:18:18.160 --> 00:18:26.160 and on and on and on, and I lost a lot of resources. Now, again, back to the advantages, 00:18:26.160 --> 00:18:31.439 we have the ability to use something like HA and start those VMs up and going again. So, 00:18:31.439 --> 00:18:38.640 I might have that initial pain of losing 30 services or 30 applications all at once, 00:18:39.280 --> 00:18:45.599 but then I have DRS bringing them back up somewhere. So, I'm only down for 5, 10, 15 00:18:45.680 --> 00:18:49.839 minutes, something like that, while we get all the different services started up, okay? 00:18:49.839 --> 00:18:55.520 And another disadvantage is it's more complicated. VMware makes virtualization just about as easy as 00:18:55.520 --> 00:18:59.839 it can be made. I just worked with a lot of different hypervisors over the years, and VMware 00:18:59.839 --> 00:19:04.719 really makes it the easiest, but it's not easy. It's not pain, you know, completely 00:19:05.839 --> 00:19:10.079 set it and forget it. It's not just check a box and everything's configured and you walk away from 00:19:10.079 --> 00:19:15.040 it. It's definitely something you have to plan and think about and, you know, put some thought 00:19:15.040 --> 00:19:20.400 and consideration into. It's complex, right? But VMware makes it about as easy as it can be made. 00:19:25.040 --> 00:19:32.479 So, I mentioned earlier about how VMware is like a suite of products. So, in the VMware vSphere 00:19:32.479 --> 00:19:37.359 ecosystem, there's a lot of products. There's Horizon for virtual desktops. There's Workspace 00:19:37.359 --> 00:19:42.719 One, which is actually, you know, a VMware-hosted solution for managing desktops and policies and 00:19:42.719 --> 00:19:47.839 things like that. NSX is software-defined networking. It's a very, very cool product 00:19:48.880 --> 00:19:52.319 that allows you to do a lot of really cool things to your network. It allows you, like I 00:19:52.319 --> 00:19:57.760 had mentioned before, create firewalls on, you know, individual VMs. Every VM is firewalled from 00:19:57.760 --> 00:20:02.560 all the others and from out in the physical world and all these things. There's all kinds of logging 00:20:02.560 --> 00:20:07.439 that's happening, all kinds of intrusion detection and prevention. You know, NSX has a lot of really 00:20:07.439 --> 00:20:13.119 great features for security. There's vSAN. vSAN is a great product if you have a bunch of servers, 00:20:13.119 --> 00:20:17.599 a bunch of storage, because maybe you were a physical environment before. This day, it's not 00:20:17.599 --> 00:20:22.560 as common as it used to be. And you're like, okay, I'm going to put ESXi on these servers, and I, 00:20:22.560 --> 00:20:26.719 you know, put things in the SAN over there. What do I do with all the disks and all these hosts? 00:20:26.719 --> 00:20:31.520 Well, vSAN lets you use those disks. Either you can use them as your primary storage for running 00:20:31.520 --> 00:20:36.640 your production VMs, or maybe you run it off your SAN and you, you know, have that as, you know, 00:20:37.599 --> 00:20:42.160 target for backup or something like that. That's very uncommon. Usually, if you're running vSAN, 00:20:42.160 --> 00:20:45.760 it's for your production workloads. But you have options and flexibility. 00:20:46.560 --> 00:20:51.839 Cloud Health basically is how it monitors your VMware environment and your vCenter and 00:20:51.839 --> 00:20:55.920 reports to you about different things that are going on. Oh, patching needs to be done. There's 00:20:56.800 --> 00:21:01.040 resource utilization is excessive. Certain services might have failed, things like that, 00:21:01.040 --> 00:21:05.839 right? Carbon Black endpoint protection is an antivirus solution, a really great antivirus 00:21:05.839 --> 00:21:14.319 solution. Workstation is a Layer 2 or Type 2 hypervisor for running on Linux and Windows, 00:21:14.319 --> 00:21:18.239 and Fusion is for running on Mac, Type 2 hypervisor for Mac. 00:21:25.920 --> 00:21:37.920 You know what, I think I'm going to tap out for the day. 00:21:40.959 --> 00:21:43.199 Yeah, I don't know if you can hear it, but I can feel it. 00:21:55.920 --> 00:22:07.119 No, I am good. I'm good. So, I don't think we meet again, unfortunately, until Monday. 00:22:15.119 --> 00:22:19.359 Well, check with Brittany. I mean, if you're, you know, supposed to be off, 00:22:19.359 --> 00:22:23.280 then great. But I'm pretty sure she scheduled me for Monday. 00:22:26.400 --> 00:22:34.400 Actually, I have nothing. She told me Monday, Tuesday, Wednesday, but nothing's on my calendar 00:22:34.400 --> 00:22:41.680 yet. She hasn't scheduled it yet, at least not with me. Yeah. So, if Monday's not an option, 00:22:41.680 --> 00:22:46.719 then, you know, I can do next week. I can do Tuesday, Wednesday, Thursday, Friday, 00:22:46.719 --> 00:22:51.040 Saturday. I know you're not available all those days. I'm just saying I'm available every day 00:22:51.040 --> 00:23:07.760 next week. Well, and also, I'm off Monday, too. So, if you wanted, like, to go do something 00:23:07.760 --> 00:23:11.680 Monday and you wanted to do it early, I can do it any time Monday, because I'm off Monday, too. 00:23:13.280 --> 00:23:19.199 So, if you want. Okay. Let me know if, again, I don't want to, if you have plans or whatever, 00:23:19.199 --> 00:23:23.119 I don't want to screw up your, you know, your time off, your holiday.