WEBVTT

00:00:00.000 --> 00:00:03.920
Welcome back to vSphere 8 in the real world. Now we're going to talk about using the host client.

00:00:08.080 --> 00:00:13.840
So when you first install ESXi, which we did in our demo, our previous demo, one of the first

00:00:13.840 --> 00:00:19.280
things you'll do after you have configured the host and you've gone into the DCUI and you know

00:00:19.280 --> 00:00:23.920
given an IP address is you'll probably want to connect to that host and start configuring other

00:00:23.920 --> 00:00:28.559
things other than just like say your management network and you know maybe the root password.

00:00:29.440 --> 00:00:34.959
You'll connect into the web interface, the host client, and you're going to log into there. You'll

00:00:34.959 --> 00:00:40.000
log in again with root and the password you configured for root either during the installation

00:00:40.000 --> 00:00:44.400
or if you changed it in the DCUI after installation, whatever you configured there.

00:00:44.400 --> 00:00:50.560
And from here you can start troubleshooting any issues with the host that you know maybe not

00:00:50.560 --> 00:00:54.720
necessarily connecting to the VM kernel interface because this wouldn't be working if that is down

00:00:54.880 --> 00:00:58.959
that's what you do to the DCUI. But then after that you might do some troubleshooting

00:00:59.599 --> 00:01:03.680
you know if you're having that kind of storage issues or virtual machine networking if using

00:01:03.680 --> 00:01:06.800
different adapters for your virtual machine you might be going to be troubleshooting some things

00:01:06.800 --> 00:01:13.199
there. You can perform administrative tasks from here. So maybe you'll create users, you're going

00:01:13.199 --> 00:01:18.160
to configure permissions that fit for those users to access different levels of the virtual

00:01:18.160 --> 00:01:23.120
machines, things like that. And then any kind of admin privileges you need to assign, right.

00:01:23.760 --> 00:01:31.120
So you can access the host by just going to https colon slash slash and either the host

00:01:31.120 --> 00:01:37.839
IP address or the name if you have it configured in your DNS. You can connect it by name or by

00:01:37.839 --> 00:01:43.040
IP address. So one of the first things you'll usually do after you get your host up and running

00:01:43.040 --> 00:01:46.800
you log in is you want to configure a login. Logging is going to be pretty critical to help

00:01:46.800 --> 00:01:51.279
you troubleshoot any issues you might have, help you discover if you even have issues sometimes.

00:01:52.239 --> 00:01:56.720
So what you'll do is in your host you're going to go to your system, go to your advanced settings.

00:01:56.720 --> 00:02:02.800
In your advanced settings you'll do a search for syslog and from there you can configure things

00:02:02.800 --> 00:02:08.000
like the rotation of your logs, the size of your log files that you want to use. You can even

00:02:08.000 --> 00:02:14.000
change the directory they're stored to. You can also configure a syslog server for your system.

00:02:14.000 --> 00:02:19.360
So you know anything logging related would be done through your system and your advanced settings.

00:02:20.000 --> 00:02:24.639
And in your system advanced settings as you can see up in the top right you just type in there

00:02:24.639 --> 00:02:29.759
your syslog and everything related to syslog would come in. And so here's where you can configure

00:02:29.759 --> 00:02:33.839
those advanced settings with the things we just discussed like the size of your log file,

00:02:33.839 --> 00:02:37.919
when you're going to rotate your log file, are you going to use a syslog server and what is

00:02:37.919 --> 00:02:42.320
the syslog server settings for that. Okay. So this is your advanced settings and again

00:02:42.880 --> 00:02:47.919
when you first connect on advanced settings you'll see just hundreds of different things in there.

00:02:47.919 --> 00:02:52.240
Just go into your search type in syslog it'll narrow down to things related to your logging.

00:02:55.360 --> 00:03:00.320
So post-installation you've installed your ESXi, you have your networking set up,

00:03:00.320 --> 00:03:03.919
so what else are you going to do? Besides configuring logging like we just discussed

00:03:03.919 --> 00:03:09.360
one of the next things that's very common to do right away will be to set up your networking.

00:03:09.360 --> 00:03:14.880
So you might go in and you might configure things like your VM networks, some things like that.

00:03:15.759 --> 00:03:20.479
How are you going to want to connect to the system to do things like configure your networking,

00:03:20.479 --> 00:03:25.360
configure your storage, start creating virtual machines? Well you can use the vSphere client.

00:03:25.360 --> 00:03:31.119
The vSphere client means that you have the system in vCenter and you're going to connect to the

00:03:31.119 --> 00:03:36.160
vSphere client to connect to vCenter to then start managing that host. Before you can manage the host

00:03:36.160 --> 00:03:39.520
in vCenter you have to add it to vCenter. So you'll log into vCenter and you're going to add

00:03:39.520 --> 00:03:43.839
the host to vCenter and then you can start managing it. If you have an Enterprise Plus

00:03:43.839 --> 00:03:48.399
license you might connect it to a distributed virtual switch so it gets all its virtual

00:03:48.399 --> 00:03:52.639
networking on there. You might want to configure your storage, whatever kind of shared storage

00:03:52.639 --> 00:03:59.679
maybe you're using. There's also the host client. So the host client is when you connect to the host

00:03:59.679 --> 00:04:06.240
IP address or the host name that resolves to its IP address. And now you're using again the web

00:04:06.240 --> 00:04:11.119
client but it's going to be a different client, has a different look and feel to it than the vCenter

00:04:11.119 --> 00:04:16.239
client does. And you can do things in there like, again, configure virtual networking, connect it

00:04:16.239 --> 00:04:21.679
to storage, create virtual machines, you know, some basic configuration in there. With the vCenter

00:04:21.679 --> 00:04:27.760
client you can also do things like create a data center, create a cluster, add the host to vCenter,

00:04:27.760 --> 00:04:33.679
add it to the cluster. If you connect to the web client you're just managing that standalone host.

00:04:33.679 --> 00:04:39.359
So even if that host is in vCenter you can still use the host client but you won't be able to use

00:04:39.359 --> 00:04:44.320
any of the vCenter features. For example, even though the host might be in vCenter, if you use

00:04:44.320 --> 00:04:48.880
the host client you can't vMotion or VM to that host or away from that host. You have to get to

00:04:48.880 --> 00:04:57.519
the vCenter client in order to do that. So managing our host, as we discussed, there's the VMware

00:04:58.799 --> 00:05:03.760
host client, right, which means you're connecting to its IP address. There's the vCenter server. So

00:05:03.760 --> 00:05:11.040
vCenter server can actually manage the VM or the host also and you don't have to use the vSphere

00:05:11.040 --> 00:05:16.320
client. That sounds kind of redundant. Well, vSphere client manages vCenter so, you know,

00:05:16.320 --> 00:05:21.040
aren't they kind of the same thing? I could have a host in vCenter and then I could connect to that

00:05:21.040 --> 00:05:26.880
vCenter server and I could actually issue, you know, commands through either Power CLI or through

00:05:27.040 --> 00:05:33.760
ESX CLI. There's different ways I can manage the host in vCenter without using the vCenter client.

00:05:33.760 --> 00:05:38.000
I could do it programmatically. I can do it through scripts, things like that. So vCenter

00:05:38.000 --> 00:05:44.799
can manage the host. The vSphere client can manage the host that's in vCenter also. That's

00:05:44.799 --> 00:05:50.559
going to give me a graphical interface to do it through. So ease of access is through a console.

00:05:50.559 --> 00:05:58.239
So if I have a VM in my, you know, on my host, I can actually open up a console for that VM

00:05:58.239 --> 00:06:02.959
and I could, you know, basically see whatever would be in on that host if I were connecting

00:06:02.959 --> 00:06:08.959
like a monitor up to a physical box. All right. That could be accessed through the web clients.

00:06:12.640 --> 00:06:18.480
So from vSphere, okay, now mind you, this is not now the web client for the host itself,

00:06:18.480 --> 00:06:25.920
the host client. From vSphere, we can remote console into our VMs, right? We can configure

00:06:25.920 --> 00:06:31.040
our virtual hardware. We can add devices. We can, you know, manage devices. For example,

00:06:31.040 --> 00:06:36.079
if I have a, you know, virtual CD-ROM drive, I can connect an ISO to that. If I have, you know,

00:06:36.079 --> 00:06:42.079
virtual NICs on the VM, I can change what port group it's connected to. I can manage the hardware

00:06:42.079 --> 00:06:47.600
through there. I can also add devices and I can do things like add a device, like choose what type

00:06:47.600 --> 00:06:52.480
of virtual device it's going to emulate. Maybe I add a virtual NIC and I say, okay, what kind

00:06:52.480 --> 00:06:57.279
of virtual NIC do I want it to be? I want it to emulate an Intel E1000. I want to use the

00:06:57.279 --> 00:07:01.359
VMXNet-3 virtual network adapter. So you can, you know, do settings like that.

00:07:02.320 --> 00:07:08.000
You can configure the networking in there. You can connect to data stores. So if you have,

00:07:08.000 --> 00:07:11.920
for example, shared storage and you have LUNs already out there with data stores on there,

00:07:11.920 --> 00:07:18.079
you can connect to those data stores. If we have raw storage on our hosts, we can also configure

00:07:18.079 --> 00:07:24.480
data stores with that local storage as well, right? And then we can also view or modify the

00:07:24.480 --> 00:07:29.359
current configurations, policies, alarms, user mappings, meaning what users are able to do and

00:07:29.359 --> 00:07:38.079
not able to do. We'll get into all that a lot more. So storage. So once we, you know, have gotten so

00:07:38.079 --> 00:07:43.600
far along, we got the host. We are connecting to our host. We want to manage storage. So vSphere

00:07:43.600 --> 00:07:47.839
is an excellent way of managing your storage because most of the time in most of your

00:07:47.839 --> 00:07:51.359
environments you're going to have, you know, these systems in the vCenter server. You're

00:07:51.359 --> 00:07:55.839
going to be connecting to shared storage. And so we can go into our hosts and we can start adding

00:07:55.839 --> 00:08:03.279
the data stores. We can configure data stores. Oh, here's my data centers. So basically a data center

00:08:04.000 --> 00:08:08.399
might be like, not necessarily have to be, but a lot of times it's like a geographic area, right?

00:08:08.399 --> 00:08:13.200
So maybe we have a data center in Houston and we have one in Seattle and we have one in New York.

00:08:13.200 --> 00:08:18.000
We'd actually go into vCenter and say, I want to create a data center, one for Seattle, one for

00:08:18.000 --> 00:08:23.359
Houston, one for New York. And then in there, I can start creating clusters and my clusters,

00:08:23.359 --> 00:08:28.239
you know, might have for however I'm dividing my servers up. Maybe I have certain types of

00:08:28.239 --> 00:08:32.880
workloads that I want these servers to run. So I might create a cluster for that. Or maybe it's

00:08:32.880 --> 00:08:37.679
for a certain group. Maybe, you know, this department has paid for these servers. These

00:08:37.679 --> 00:08:42.320
are their servers. And so I'm going to go in there and create a finance cluster. This kind of depends

00:08:42.320 --> 00:08:47.039
on how you're going to do that. What you might also see is based upon hardware. Maybe I have a

00:08:47.039 --> 00:08:51.760
cluster for these servers that I bought three years ago and their CPUs aren't compatible with

00:08:51.760 --> 00:08:56.239
the brand new servers I bought this year. So I create one cluster for the three years ago CPUs

00:08:56.239 --> 00:09:01.599
and another cluster for this year's servers, CPUs, right? So you can create data centers,

00:09:01.599 --> 00:09:06.719
you can create clusters, you can then assign permissions. And you can say that these users

00:09:06.719 --> 00:09:12.000
over here are able to see the servers in the finance cluster, but they can't make changes

00:09:12.000 --> 00:09:16.799
and they cannot see any of the other servers and any of the other clusters. And this other user,

00:09:16.799 --> 00:09:21.359
Bob, over here, he's actually the admin for finance and he's able to make changes onto that

00:09:21.359 --> 00:09:25.280
cluster. So you can assign permissions. You can configure the message of the day. So when they

00:09:25.280 --> 00:09:32.960
log in, they see a banner. Security management, you can configure user accesses and things like

00:09:32.960 --> 00:09:38.479
that. You can manage vSAN if you have local storage and these hosts that you want to deploy

00:09:38.479 --> 00:09:43.359
with vSAN, you can manage vSAN through here. And health checks. So health checks will basically

00:09:44.159 --> 00:09:51.039
tell us if we have software out of date, or if we have configurations that aren't healthy,

00:09:51.039 --> 00:09:57.919
or if we have poor performance on – or poor utilization on a certain network adapter or CPU,

00:09:57.919 --> 00:10:02.960
or if my vSAN has errors in there or something like that. All that can show up under my health

00:10:02.960 --> 00:10:11.280
checks. So managing storage, we talked about creating data centers, right? Talk about

00:10:11.280 --> 00:10:20.239
configuring the data center. Capacity. So we can go into our storage and we might have – maybe

00:10:20.239 --> 00:10:26.719
we have a LUN that is given to me and it's six terabytes. I can decide if I want to deploy

00:10:26.719 --> 00:10:32.320
a data store that takes up the entire LUN, the whole six terabytes, or maybe I only need a small

00:10:32.320 --> 00:10:36.799
LUN for a certain cluster for a small number of VMs, so I'm only going to use one terabyte or

00:10:36.799 --> 00:10:43.119
750 gigs or something like that. Storage control. So again, we talked about storage IO control.

00:10:43.119 --> 00:10:48.960
We can configure storage IO control if we have licenses for that. We can configure to make sure

00:10:48.960 --> 00:10:55.599
that VMs don't overutilize the amount of IO to storage that they should. We don't want one VM,

00:10:56.880 --> 00:11:01.599
the term noisy neighbor has been thrown around quite a bit online, a noisy neighbor VM using a

00:11:01.599 --> 00:11:06.159
lot of IO and kind of drowning out other VMs. Storage IO control makes sure that everything's

00:11:06.159 --> 00:11:11.440
done kind of evenly and equally. We can also say this VM over here is pretty important and we want

00:11:11.440 --> 00:11:16.880
to give it a higher priority. We want to give it more access to storage. So it actually does get

00:11:16.880 --> 00:11:22.320
more IO. We can say how much more. We can control the amount of additional IO it gets compared to

00:11:22.320 --> 00:11:32.239
the other VMs. So space reclamation. If we have a storage array that supports the storage APIs

00:11:32.239 --> 00:11:38.960
for VMware, what can actually happen is you'll see like virtual disks, for example, can start

00:11:38.960 --> 00:11:42.719
growing, growing, growing. And maybe you go in like, oh wow, we put a bunch of data on here. We

00:11:42.719 --> 00:11:47.599
don't need this temporary data there anymore. Let's delete all this temporary data. We delete

00:11:47.599 --> 00:11:56.320
500 gigs of data off of there. But your VMDK file doesn't get any smaller, right? If it's a thin

00:11:56.320 --> 00:12:02.320
provision VMDK, it will get bigger, but it doesn't get any smaller. Well, actually what you can do

00:12:02.320 --> 00:12:07.840
is you can have your systems, your storage arrays communicating with vCenter and realize that,

00:12:07.840 --> 00:12:14.559
you know what, we can get rid of all this space here. We can free up this space. A LUN might be

00:12:14.559 --> 00:12:22.400
set to grow and shrink also. And you delete the VMDK off the LUN, but the LUN doesn't shrink back

00:12:22.400 --> 00:12:27.280
down. So we can actually have it go in and zeroize information. It can go through and zero and

00:12:27.280 --> 00:12:33.760
reclaim space that has been freed up. And so that space is now presented back to the storage array

00:12:33.760 --> 00:12:39.440
as being available for another VM or another host or some other function on that storage array.

00:12:42.799 --> 00:12:52.239
Storage and CPU. So time to manage networking. So in your network, you might want to monitor

00:12:52.239 --> 00:12:58.719
the activities that's going on. There actually is performance charts for, you know, CPU,

00:12:58.719 --> 00:13:02.799
for storage, for memory, and for your networking. So you can actually go in there and look at

00:13:02.880 --> 00:13:07.520
physical adapters and see how utilized and how much traffic is being, you know, sent,

00:13:07.520 --> 00:13:11.919
how much is being received. You can also look at it on the VM level. You can see how much traffic

00:13:11.919 --> 00:13:17.760
VMs are sending and how much traffic VMs are receiving as well, right? So you can manage

00:13:17.760 --> 00:13:23.520
the performance or monitor performance through your performance charts. You can manage permissions.

00:13:23.520 --> 00:13:27.359
Again, we've discussed permissions quite a bit. Same thing. You can say who can configure virtual

00:13:27.359 --> 00:13:32.000
switches or who can't configure switches and who can change VMs, you know, virtual network adapter

00:13:32.000 --> 00:13:38.320
settings, things like that. You can move your VMs to other networks. So what can happen is you

00:13:38.320 --> 00:13:43.119
have your virtual NIC and your virtual NIC is attached to a port group. You can go in and

00:13:43.119 --> 00:13:47.760
change it to a different port group. Just keep in mind that moving to a different port group often

00:13:47.760 --> 00:13:53.359
means you put it onto a different VLAN. Different VLAN means you need to re-IP that virtual machine,

00:13:53.359 --> 00:13:57.599
unless for some reason you have two different VLANs that are using the same IP subnet range and

00:13:57.599 --> 00:14:00.559
then you've probably got some other issues going on that you need to address there.

00:14:02.479 --> 00:14:08.960
You can specify which VMs are going to be on what networks, and you can go in and actually

00:14:08.960 --> 00:14:14.960
monitor traffic, and then you can say, okay, I have these physical adapters on this virtual switch,

00:14:14.960 --> 00:14:19.840
and you can specify that you want this one to be active, you want this one to be standby,

00:14:19.840 --> 00:14:23.520
maybe you want them both to be active, and then if you do want them both active,

00:14:23.520 --> 00:14:27.119
you can say how you want the VMs assigned to the different adapters.

00:14:27.119 --> 00:14:33.119
What will happen is a VM will be some kind of load balancing algorithm. You can say I want to

00:14:33.119 --> 00:14:38.960
be based on an IP hash of the source and destination IP. I want to be based upon the virtual port on

00:14:38.960 --> 00:14:42.719
the switch the virtual machine connects to. So this port's going to connect to the first NIC,

00:14:42.719 --> 00:14:47.919
and the next virtual port connects to the second NIC. You can balance them that way.

00:14:47.919 --> 00:14:51.119
So there's a lot of different configurations on your virtual networking that you'll want to

00:14:51.119 --> 00:14:56.880
configure, and how you configure that can have an impact on how your VMs are formed.

00:14:56.880 --> 00:15:02.000
If you have multiple adapters, but only one is set to active, you might find that your performance

00:15:02.000 --> 00:15:06.320
is not as good because maybe you're overloading that adapter. If you made one of the standby

00:15:06.320 --> 00:15:14.320
adapters also active, then you have to configure the switch so that the ports those NICs connect on

00:15:14.320 --> 00:15:20.320
are set for a lag, but not a dynamic lag for a static lag, and then they can balance the load

00:15:20.320 --> 00:15:30.719
for the VMs across those adapters. This is talking about if you're upgrading our ESXi 7

00:15:30.719 --> 00:15:37.200
systems to ESXi 8, and we're running certain Dell PowerEdge servers. If we use the Dell ISO for

00:15:37.200 --> 00:15:42.719
version 7, then there is going to be drivers installed that have been depreciated, and those

00:15:42.719 --> 00:15:49.520
depreciated drivers don't have a version 8 to go to, and so the installation fails. So what you'll

00:15:49.520 --> 00:15:56.239
need to do is go in and basically just SSH the host and remove the bad drivers, or bad drivers

00:15:56.239 --> 00:16:00.960
is the last right word, the depreciated drivers, the ones that they're no longer using, so that

00:16:00.960 --> 00:16:05.599
way 8 doesn't try to upgrade that and say I don't have a version for that and fail. We've removed it

00:16:05.599 --> 00:16:10.640
from version 7, and the version 8 upgrade goes smoothly. I've seen that before with HP devices

00:16:10.640 --> 00:16:14.159
too, going from like 6.5 to 7 and things like that. It's a pretty common issue to have.

00:16:14.960 --> 00:16:19.440
So some best practices. Basically, one of the things to keep in mind when you're doing a virtual

00:16:19.440 --> 00:16:25.039
environment is virtual and physical are very different. When you buy physical servers, you

00:16:25.039 --> 00:16:30.559
normally buy the most your budget is going to afford you. You want the most CPU you can afford,

00:16:30.559 --> 00:16:36.719
the most RAM you can afford, the fastest and biggest hard drives you can afford. When you're

00:16:36.719 --> 00:16:41.760
doing virtual environments, you want to kind of do the exact opposite. You want to go slow,

00:16:41.760 --> 00:16:49.760
opposite. You want to go sparingly. Give it the minimal hardware that it needs to perform its job

00:16:49.760 --> 00:16:56.640
at the level you want it to. If the machine can do its job and do it well, the virtual machine

00:16:56.640 --> 00:17:03.200
can do it well with two virtual CPUs, don't give it 8. If it only needs 4 gigs of RAM to run its

00:17:03.200 --> 00:17:09.119
workload and run it effectively, again, don't give it 8, don't give it 12, don't give it 24 gigs.

00:17:09.119 --> 00:17:15.760
Give it the minimal resources it needs because what happens is that all these VMs using more

00:17:15.760 --> 00:17:20.880
resources than they need, it also creates overhead. And overhead is something that

00:17:20.880 --> 00:17:25.040
it's additional work on top of the host that it takes to run those virtual machines.

00:17:26.000 --> 00:17:33.839
If the VM has too many virtual CPUs, the host can say, well, we're not scheduling these,

00:17:33.839 --> 00:17:38.160
so I'm going to schedule them for another VM someplace else. But that overhead that it takes

00:17:38.160 --> 00:17:42.959
to manage that doesn't go away. That does not decrease. The overhead never gets redeemed by

00:17:42.959 --> 00:17:49.680
the host because you're not using that resource. So you'll find also that it's hard for the host

00:17:49.680 --> 00:17:58.079
to schedule a lot of VMs with a lot of virtual CPUs that greatly exceed the number of physical

00:17:58.079 --> 00:18:03.599
cores or virtual cores that the host has in it. There's a scheduling service. The scheduling

00:18:03.599 --> 00:18:10.959
service will say, this VM has four virtual CPUs. I only need to run two threads. I only need

00:18:10.959 --> 00:18:16.800
two cores. But the VM has four virtual CPUs. I have to schedule all four together. I can't

00:18:16.800 --> 00:18:22.719
schedule only two. So if the VM has eight, then it has to schedule all eight at once.

00:18:22.719 --> 00:18:28.959
And if you're only needing to run two threads, the other six cores are assigned, but they're not

00:18:28.959 --> 00:18:33.920
doing any work. And other VMs that could be using those cores don't have access to them.

00:18:34.800 --> 00:18:42.000
So assigning too many virtual CPUs can negatively impact the performance of your

00:18:42.000 --> 00:18:46.880
virtual environment if they're not necessary. Same thing with assigning too much RAM.

00:18:48.000 --> 00:18:51.760
There's a lot of overhead involved with managing that. And as you know, a Windows system

00:18:52.880 --> 00:18:57.119
maybe only needs four, but you gave it eight, it's going to suck up eight. And it's going to

00:18:57.119 --> 00:19:02.479
sit in physical RAM at eight. And if you were to reduce that VMs down to four,

00:19:02.479 --> 00:19:07.119
you'd find the performance all of a sudden is fine, is acceptable, and the other VMs are

00:19:07.119 --> 00:19:12.479
performing better as well. So make sure that you're sizing your VMs appropriately for the

00:19:12.479 --> 00:19:18.479
workloads you're running. Start small. It's really easy to add. It's not always as easy

00:19:18.479 --> 00:19:22.800
to take away because users get used to a certain level of performance. And as you're taking things

00:19:22.800 --> 00:19:29.119
away, they might see a small hit, which maybe is within your SLA, but it's not what they're used to

00:19:29.119 --> 00:19:35.359
and they're going to complain. All right. So some of the best practices are just use the resource

00:19:35.359 --> 00:19:40.959
you need. Use the minimal amount that you need to get the work done properly. Also, when you're

00:19:40.959 --> 00:19:48.160
sizing your hosts, having multiple medium-sized hosts is often better than a smaller number of

00:19:48.160 --> 00:19:54.800
very large hosts. Because if you have, let's say you have three very large, beefy hosts with

00:19:55.520 --> 00:20:01.359
a terabyte of RAM and just super fast gold-level Intel Xeon processor CPUs and all that kind of

00:20:01.359 --> 00:20:07.040
stuff, and one of those hosts fails, it may take down a large number of VMs. Where if we had taken

00:20:07.040 --> 00:20:14.000
that same money and scaled out and had maybe six hosts or eight hosts or nine hosts, and one fails,

00:20:14.000 --> 00:20:21.199
I lost a smaller number of VMs. Now, HA should restart those VMs for me, but the impact to the

00:20:21.199 --> 00:20:27.359
users while that restart happens is going to be a lot less with moderate-sized, more hosts.

00:20:27.359 --> 00:20:31.920
Right? Now, there are other things to consider if you're in, for example, if you're in a colo location

00:20:31.920 --> 00:20:36.000
and you're paying for rack space and you have to get a second rack, that makes it more expensive.

00:20:36.880 --> 00:20:43.040
Power is questionable. Maybe that might take up more power that way. The bigger CPUs take a lot

00:20:43.040 --> 00:20:48.239
more power. The smaller ones kind of even that out sometimes. So there's a lot of considerations

00:20:48.239 --> 00:20:54.239
in there, but scaling out is usually a good idea. Having moderate-sized hosts that you can scale out

00:20:54.239 --> 00:20:59.680
for failure is sometimes a good idea. But of course, your environment might really require

00:20:59.680 --> 00:21:05.119
big, beefy hosts that can run a smaller number of big VMs. Then you need large hosts that can

00:21:05.119 --> 00:21:11.680
run those big VMs. There's always going to be conversations that make things valid one way

00:21:11.680 --> 00:21:17.199
or the other. You should look at your environment and just take a serious look at what would work

00:21:17.199 --> 00:21:21.199
best for you and don't just automatically assume get the biggest host you can, because that's not

00:21:21.199 --> 00:21:30.319
always the best use of your resources. Okay? So some memory best practices, same kind of thing.

00:21:32.560 --> 00:21:39.280
Size appropriately. If you are committing more memory than is needed, you might also start

00:21:39.280 --> 00:21:43.680
running into issues where you've over-allocated RAM. That increases the overhead, as we mentioned

00:21:43.680 --> 00:21:49.040
before, on the host. And what starts happening is the host is going to start doing some things to

00:21:49.040 --> 00:21:54.319
try and manage the memory of those VMs to make sure it can allocate all that it needs. So one

00:21:54.319 --> 00:21:59.359
thing it does is page sharing. By default, page sharing is turned off. It used to be on by default.

00:22:00.640 --> 00:22:06.319
It was a paper written several years back saying that it might be a security vulnerability. So by

00:22:06.319 --> 00:22:11.599
default, transparent page sharing has been turned off by default. But you can go in there and turn

00:22:11.599 --> 00:22:17.439
it back on and fill an option. And what that basically means is that if I'm running five VMs

00:22:17.439 --> 00:22:24.079
and they're all running the exact same version of Windows Server 2000 and 2016 with the same patch

00:22:24.079 --> 00:22:29.680
levels and everything, there's probably a lot of pages that are exactly the same from the operating

00:22:29.680 --> 00:22:35.920
system, for example, on all the hosts. So rather than write those pages five times for five VMs,

00:22:36.479 --> 00:22:41.680
I write it once and I point all five VMs to that same physical page in memory. All right, that's

00:22:41.680 --> 00:22:47.760
transparent page sharing. By default, that is turned off. What ballooning is is that if a VM

00:22:47.760 --> 00:22:55.359
is using a lot of physical RAM, there's a driver with VMware Tools. You have to have VMware Tools

00:22:55.359 --> 00:22:59.199
installed in order for ballooning to work. And you always want VMware Tools installed anyway for

00:22:59.199 --> 00:23:05.040
performance reasons. The host can trigger the balloon driver in a VM. And that balloon driver,

00:23:05.040 --> 00:23:11.439
all it does is start eating up RAM. It just eats up a bunch of RAM. And the host can see the RAM

00:23:11.439 --> 00:23:15.920
that's being eaten up by the balloon driver. And so what's happening is the host, I'm sorry,

00:23:15.920 --> 00:23:21.280
the virtual machine that's launching that balloon driver is starting to write what was in that RAM

00:23:21.280 --> 00:23:25.760
to its page file. It knows what's more important or what's least important to have in RAM.

00:23:26.319 --> 00:23:32.000
And the less important information gets written to its page file in the VM. The host sees the

00:23:32.000 --> 00:23:37.359
balloon driver and says, okay, that's balloon driver, so I don't actually have to put that into

00:23:37.359 --> 00:23:43.280
physical RAM. That frees up physical RAM on the host to use for other VMs. And then the virtual

00:23:43.280 --> 00:23:46.880
machine will start taking things from the page file and loading it back in RAM. You might start

00:23:46.880 --> 00:23:51.520
seeing the RAM fill up again. Or maybe it's stale information that's been sitting there for a while

00:23:51.520 --> 00:23:55.760
and isn't going to be accessed again for a while. And we just, you know, maybe solve a problem.

00:23:56.479 --> 00:24:03.199
Memory compression is basically where the hypervisor starts compressing

00:24:04.160 --> 00:24:08.959
information in pages of RAM to try and make it smaller so we can free up RAM.

00:24:08.959 --> 00:24:15.599
That obviously is very CPU intensive. Then there's the host swap. So, this traditional regular host

00:24:15.599 --> 00:24:20.719
swap means that we can take what's in RAM for a VM. Maybe the balloon driver's already tried

00:24:20.800 --> 00:24:26.400
its thing and all these different things of RAM. And it starts page into that VM's. Each VM will

00:24:26.400 --> 00:24:32.239
have their own page file, right? So, we can't start taking things that's for a, you know, VM1

00:24:32.800 --> 00:24:38.719
and put it into VM1's page file. The VM thing is actually in RAM. But the host knows that,

00:24:38.719 --> 00:24:43.359
well, when the VM asks for this page in memory, I've written that to a page file. So, you see,

00:24:43.359 --> 00:24:48.319
that's why the balloon driver is better. Because the balloon driver lets the VM pick what to page.

00:24:48.319 --> 00:24:54.079
When the host starts writing things from physical RAM to the VM's page file on the

00:24:54.079 --> 00:25:00.319
VMFS data store, the host doesn't know what's important or not important to the VM.

00:25:00.319 --> 00:25:06.239
It's picking for it. So, you're better off using the balloon driver. But if we tried that,

00:25:06.239 --> 00:25:13.199
still need more RAM. We tried compression. We still need more RAM. We can use the VM's page file.

00:25:13.199 --> 00:25:17.839
And then this regular, you know, regular host level swapping just for their host's own,

00:25:17.839 --> 00:25:21.520
you know, swap file for its own functionality is another option for

00:25:21.520 --> 00:25:24.800
the host has to try to free up RAM in its system.

00:25:28.319 --> 00:25:35.760
So, for storage, if you're using shared storage, it's always a good idea to try and use a storage

00:25:35.760 --> 00:25:45.760
vendor that supports the vStorage APIs for array integration. So, VAI. Basically, it's APIs that

00:25:45.760 --> 00:25:52.640
the host can use to communicate with the storage array to do things like zero out, you know,

00:25:52.640 --> 00:26:01.439
unused pages, unused blocks on a disk. It also can use it to say, I need to write a new VMDK

00:26:01.439 --> 00:26:07.359
file, and that VMDK file is going to be thick provision eager zeroed. So, I need to write a

00:26:07.359 --> 00:26:13.119
bunch of zeros. The host could just start saying, write 0, 0, 0, 0, 0, 0, you know, until it's

00:26:13.119 --> 00:26:19.119
filled up this VMDK file. Or it can say, create a VMDK file and fill it full of zeros. And then it

00:26:19.119 --> 00:26:24.400
just hands it off to the storage array. The storage array does it. The host can also say, I need to

00:26:24.400 --> 00:26:32.160
move a VM from this LUN, from this datastore, to this datastore. And if it's on one storage array,

00:26:32.160 --> 00:26:39.520
the host could start reading and writing, you know, over the network. Or it could tell the

00:26:39.520 --> 00:26:45.359
storage array, move that VM over there from here to here. And just hand off the work to the storage

00:26:45.359 --> 00:26:49.760
array. It can monitor it. And when it's done, the storage array says this task is complete.

00:26:49.760 --> 00:26:55.280
And the host can tell you your storage vMotion is complete. So, basically, it allows the host

00:26:55.280 --> 00:27:01.520
to hand off jobs to the storage array so that, one, the host isn't doing the work. It's not taking

00:27:01.520 --> 00:27:05.280
up resources on the host. It's not taking up resources over the network. And the storage

00:27:05.280 --> 00:27:11.119
array can do it internally much faster than the host can do it over the network. So, that's

00:27:11.119 --> 00:27:18.719
the APIs. And those are a really, really good idea. Most storage vendors, especially if they are

00:27:18.719 --> 00:27:25.839
any kind of VMware partner, obviously, support the APIs. So, for virtual disks, there's obviously

00:27:25.839 --> 00:27:30.000
some different ways we can create virtual disks for our virtual machines that will be on that

00:27:30.000 --> 00:27:37.520
storage. We have independent persistent disks. And those were considered for best for performance.

00:27:37.520 --> 00:27:42.160
Okay? So, with an independent persistent disk, basically, what's going to happen is,

00:27:42.959 --> 00:27:50.160
excuse me, we can create a VM and we can, you know, run it. And then when we're done,

00:27:50.160 --> 00:27:54.079
we can shut it down. And when we turn it on again, it's like it was we turned on the first time.

00:27:54.079 --> 00:28:00.239
Whatever was happening and done to it doesn't take up, isn't saved. Nothing's saved on that disk.

00:28:00.239 --> 00:28:06.000
Okay? Independent non-persistent has review logs. So, basically, what that is, if you take a

00:28:06.000 --> 00:28:12.239
snapshot on that, it actually snapshots. With the persistent disk, there's snapshots don't

00:28:12.239 --> 00:28:18.239
happen. Nothing really happens on it. Dependent disks, those are actually just our regular

00:28:18.239 --> 00:28:23.199
everyday disk. That's the default. A dependent disk is a regular disk. So, when you write to

00:28:23.199 --> 00:28:28.000
the disk, the changes get written to the disk. So, if you create a new VM, you install an OS,

00:28:28.000 --> 00:28:35.040
you save a file to it, the file gets saved. If you take a snapshot, the snapshot file gets created.

00:28:35.040 --> 00:28:41.599
All the changes from that point forward get saved to that difference file. That's that snapshot.

00:28:41.599 --> 00:28:46.239
And then you can say if you want to, you know, just basically save the snapshot,

00:28:46.239 --> 00:28:51.760
you want to delete it and save the state, it all gets merged into one VMDK file. Or you can say

00:28:51.760 --> 00:28:56.400
delete it and roll back the way it was before. All right? So, dependent disks are the default

00:28:56.400 --> 00:29:03.839
disks that you always use. Independent persistent or non-persistent basically means that we don't

00:29:03.839 --> 00:29:07.839
want changes to be made, right? And we don't want to be using snapshots on them.

00:29:12.560 --> 00:29:18.959
So, disk types. There's two disk types when you create a new VMDK file. There's thick provisioned

00:29:18.959 --> 00:29:23.680
and there's thin provisioned. A thin provisioned disk means that it basically just creates a small

00:29:23.680 --> 00:29:29.680
file that kind of a placeholder for that virtual disk. And as you write to it, the file is going

00:29:29.680 --> 00:29:35.439
to grow. It grows in blocks. The thing about that is that growing actually gives you a small

00:29:35.439 --> 00:29:41.680
performance hit every time you have to grow the file. The advantage of it is that if it's a,

00:29:41.680 --> 00:29:48.000
say, 500 gig VMDK but it's thin provisioned and you're only using 10 gigs, it's only 10 gigs in

00:29:48.000 --> 00:29:53.839
size. It's not 500 gigs in size. So, thin provisioned is a very efficient way of using space,

00:29:54.560 --> 00:29:59.839
but it's not as good for performance reasons. Then there's thick provisioned. If you thick

00:29:59.839 --> 00:30:05.520
provision a disk and you say it's 500 gigs when you first create it and there's nothing in there,

00:30:05.520 --> 00:30:11.599
it's 500 gigs. The whole amount of space is allocated all at once. Then the question is,

00:30:11.599 --> 00:30:17.839
do you want it to be lazy zeroed or do you want to be eager zeroed? If you make it thick provisioned

00:30:17.839 --> 00:30:25.280
and eager zeroed, the system goes and it writes zeros to all the blocks in that virtual disk and

00:30:25.280 --> 00:30:30.160
zero out the whole thing before it says it's done and it's ready for use. So, that can take a while.

00:30:30.880 --> 00:30:36.640
It might take a while to create that VMDK file. And it obviously is going to create some overhead

00:30:36.640 --> 00:30:42.880
on the storage arrays and work around the network. Lazy zeroed says create the 500 gig disk,

00:30:42.880 --> 00:30:48.079
but what happens is the first time you write to a block, it zeros out the block. Then it writes

00:30:48.079 --> 00:30:51.760
your data. And if you go to write to another block, it zeros out that block, and then it

00:30:51.760 --> 00:30:58.479
writes your data. A block has to be zeroed out the first time it's written to. So, it can either be

00:30:58.479 --> 00:31:04.479
eager zeroed, written out in advance, or lazy zeroed, written zeroed out as you use it.

00:31:04.479 --> 00:31:09.359
Performance-wise, obviously, the eager zeroed is going to give you the very best performance.

00:31:09.359 --> 00:31:13.359
And lazy zeroed will give you the next best because it doesn't have to grow the file,

00:31:13.359 --> 00:31:18.959
but it does have to zero it. Thin provision is going to give you the least good performance,

00:31:18.959 --> 00:31:24.160
the worst performance, because you have to grow the file and zero out the blocks as you go along.

00:31:24.959 --> 00:31:31.040
So, I think the default is thick provision lazy zeroed for a lot of situations.

00:31:31.040 --> 00:31:38.160
If you have, again, the storage API and you do choose to do a thick provision eager zeroed,

00:31:39.040 --> 00:31:42.640
it happens, actually, pretty quick because it hands it off to the storage array. The storage

00:31:42.640 --> 00:31:48.239
array says, yep, I got that done, and the system can go on with what it's doing while it zeros out

00:31:48.239 --> 00:31:53.199
that VMDK file. All right. So, before we wrap up this lesson, let's go ahead and do a quick demo

00:31:53.199 --> 00:31:58.479
where I'll show you what the vSphere client and the web management client for the ESXi host looks

00:31:58.479 --> 00:32:03.520
like. So, here we have the host client, the management client for the vSphere ESXi host

00:32:03.520 --> 00:32:09.359
itself. So, I'm going to go ahead and log in here. Username is root and the password.

00:32:14.479 --> 00:32:18.880
So, here, when we log into the vSphere host, you'll see the vSphere host is actually a little

00:32:18.880 --> 00:32:24.000
different. The vSphere client is a little different than for the host itself. So, we can

00:32:24.000 --> 00:32:28.560
see if we have any virtual machines created on this host, any storage that might be configured on

00:32:28.560 --> 00:32:34.560
this host, right? Under storage, we can see if we have data stores. All right. We have one data

00:32:34.560 --> 00:32:43.760
store, which is just on local storage. If we have any devices, let's go back to here and look at

00:32:43.760 --> 00:32:50.640
devices, and you can see we have a CD-ROM drive, and we have that local disk on this host here

00:32:51.199 --> 00:33:00.400
configured. Under networking, we have port groups. We have some virtual switches, and actually,

00:33:00.400 --> 00:33:04.239
virtual switches are the highest level, and then you have port groups,

00:33:05.520 --> 00:33:10.560
right, on those virtual switches. So, if we were to go to the switch itself,

00:33:11.920 --> 00:33:16.800
we would see we have a management port group on here. We have that vMotion port group on here,

00:33:16.800 --> 00:33:22.719
and if we go back to networking and port groups, you see we have management, we have vMotion,

00:33:22.719 --> 00:33:28.880
and then on our virtual switch, we have a storage virtual switch, and we have a

00:33:31.920 --> 00:33:37.599
VMkernel port that is configured. If I go to my VMkernel port,

00:33:38.239 --> 00:33:45.439
I have an iSCSI vMkernel adapter. Let's go to edit the settings,

00:33:46.239 --> 00:33:49.439
and you'll see it's on that iSCSI port group, right? So,

00:33:58.239 --> 00:34:03.599
we have our – I'm sorry, storage – I'm sorry. The name of the port group was iSCSI,

00:34:03.599 --> 00:34:08.239
and it's on the storage virtual switch, storage port group, right? So, go ahead and go back to

00:34:08.239 --> 00:34:14.159
networking, go back to our port groups. We have our iSCSI port group on there. All right,

00:34:14.719 --> 00:34:18.159
and then we have our storage virtual switch.

00:34:24.719 --> 00:34:30.159
Then, under networking, we also have our physical NICs. So, we can see all of our physical adapters

00:34:30.159 --> 00:34:36.159
and we can see, you know, the – now, this driver, this is because this host is actually a virtual

00:34:36.159 --> 00:34:40.560
machine, and so this is the adapter that's installed on it, so it's the driver that's being used,

00:34:41.520 --> 00:34:45.520
our MAC address that's on there. We can also look at switches,

00:34:48.959 --> 00:34:54.719
and on the switch, we can see what physical adapters are on this virtual switch,

00:34:54.719 --> 00:35:03.679
we can go back to our physical NICs, see? And then, we can go to our storage,

00:35:05.679 --> 00:35:09.679
and we have one NIC attached to that. So, there's actually one NIC that's currently,

00:35:09.679 --> 00:35:16.479
one physical adapter on this host that's not assigned to a virtual switch, all right?

00:35:16.800 --> 00:35:20.399
Now, we're going to get into this in a lot more depth in a later lesson where we'll actually go

00:35:20.399 --> 00:35:26.639
into the switch and we'll look at the settings on the switch, and we'll talk about the uplinks.

00:35:26.639 --> 00:35:31.280
We're going to talk about what the link discovery and security, what all these different things

00:35:31.280 --> 00:35:36.000
mean. So, I just want to do a quick walkthrough and show you this interface currently.

00:35:37.120 --> 00:35:40.479
So, we're going to go ahead and go ahead and get started. So, we're going to go ahead and

00:35:40.560 --> 00:35:44.399
what all these different things mean. So, I just want to do a quick walkthrough and show you

00:35:44.399 --> 00:35:49.600
this interface currently, right? On the host itself, the two main things you're going to,

00:35:49.600 --> 00:35:53.360
you know, do other than maybe have virtual machines is you'll probably configure the

00:35:53.360 --> 00:35:57.520
networking and you'll configure storage if you have any storage you need to configure, right?

00:35:57.520 --> 00:36:04.719
If we go to TCPIP stacks, we can see, like, we have an IP address configured on this guy here.

00:36:05.280 --> 00:36:12.000
Under firewall rules, you can see if you have any services enabled in the firewall policy open.

00:36:12.000 --> 00:36:17.120
DHCP is open on here. If I scroll down, you should have an iSCSI. Let's see.

00:36:18.479 --> 00:36:24.639
Software iSCSI client, right? That is enabled. That policy is enabled. SSH is enabled. So,

00:36:24.639 --> 00:36:30.399
that's your firewall rules there. All right. And we don't have any virtual machines currently

00:36:30.399 --> 00:36:39.280
on this host. All right. Now, also, the client for vCenter, it does a lot more.

00:36:39.280 --> 00:36:46.159
It's actually really different. So, our vCenter IP address is this guy.

00:36:49.040 --> 00:36:56.800
So, let's just go ahead and log in there. Now, launch our vSphere client.

00:37:01.360 --> 00:37:05.439
So, I'll log in. So, here, you can see,

00:37:10.560 --> 00:37:17.360
here we have our vCenter. Here we have a data center for our Houston data center,

00:37:17.360 --> 00:37:24.239
and we have a data center configured for our LA data center. We have a cluster configured in here.

00:37:24.239 --> 00:37:29.199
Notice it's really different, right? So, here, we have a different place to go to look at data

00:37:29.199 --> 00:37:35.679
stores. We have a different place to go to look at networks. And even though here we have networks,

00:37:35.679 --> 00:37:40.639
if we want to configure our networks, we're going to go to configuration. And then from here,

00:37:42.159 --> 00:37:46.159
we could go in and configure, you know, different types of services and things like that, right?

00:37:47.760 --> 00:37:57.360
If I were to add a host to this, let's just say we add this host in there for right now.

00:37:59.199 --> 00:38:18.879
So, we're going to say that's the host we're going to add. We're okay with that

00:38:19.360 --> 00:38:22.560
SHA-1 thumbprint, SHA-1 thumbprint.

00:38:36.000 --> 00:38:38.239
Give that a moment to come the rest of the way in. It takes a moment.

00:38:39.199 --> 00:38:46.560
So, here, we can see the tasks are going on. You can see the tasks that have already been completed,

00:38:47.919 --> 00:38:50.560
right? And you can see the ones that are still in progress.

00:38:52.000 --> 00:38:55.600
You could also look, for example, on that cluster. You can go to monitor.

00:38:58.560 --> 00:39:04.639
So, there's the host that's already added. You can see tasks listed here that were related to

00:39:04.719 --> 00:39:09.520
you can see tasks listed here that were related to that cluster.

00:39:09.520 --> 00:39:13.360
Here we have a host, right, added. We're going to go ahead and take it out of maintenance mode.

00:39:18.399 --> 00:39:26.959
All right. And so, we've really got networks over here. You see we have the networks that

00:39:26.959 --> 00:39:35.840
were on that host on here. Let's go ahead and just give us some more room. We can go to configure

00:39:37.439 --> 00:39:43.199
and here's virtual switches. There's the management, right, the vMotion one we saw before.

00:39:48.959 --> 00:39:51.919
Here is that storage virtual switch. Here's the iSCSI

00:39:52.639 --> 00:39:56.800
port group and our vMkernel port for our iSCSI, right? So, the adapters that are on there,

00:40:00.959 --> 00:40:06.159
right, with adapters are mapped to the switch. So, quite a bit on there. Notice all of a sudden now

00:40:06.800 --> 00:40:12.959
we've got a virtual machine. Because we are adding a host to a cluster, it deploys this

00:40:12.959 --> 00:40:17.439
virtual machine. It deploys two or three of them into the cluster and these are actually

00:40:17.439 --> 00:40:22.239
completely managed by vSphere. We don't do anything with these. We don't start them up.

00:40:22.239 --> 00:40:27.280
We don't shut them down. We don't do anything with them. And vSphere is going to manage these

00:40:27.280 --> 00:40:33.120
virtual machines, which are used for managing the cluster for, you know, seeing up and down

00:40:33.120 --> 00:40:40.879
times and things like that. So, it's still doing its thing. You can see it's deploying

00:40:40.879 --> 00:40:44.479
that virtual machine still. That task is not complete, which is why it's still powered off.

00:40:45.120 --> 00:40:51.040
So, the real thing I wanted to show you is just how different the host interface is

00:40:52.399 --> 00:41:00.080
compared to vCenter, right? Whereas on the host, we have a place to go for networking and we can

00:41:00.080 --> 00:41:04.399
see our network and configure our network and all that kind of stuff from here. But in vSphere,

00:41:05.199 --> 00:41:09.840
we have one place we can go and just view our networking, but we also, under configuration,

00:41:09.840 --> 00:41:15.439
can go in and configure virtual switches, configure VM kernel adapters, manage our

00:41:15.439 --> 00:41:21.840
physical adapters, TCP IP configuration. We have configurations for virtual machines, the system,

00:41:21.840 --> 00:41:28.479
right? A lot of different options all under configuration. We're going to go into quite

00:41:28.479 --> 00:41:33.040
a bit of all this stuff as we get into other adapters. We'll have storage. We'll talk about

00:41:33.040 --> 00:41:36.959
configuring storage when we get into those lessons. But right now, I just wanted to show you

00:41:36.959 --> 00:41:42.159
that this is what you're going to do to manage vSphere. So, we had multiple hosts. We have our

00:41:42.159 --> 00:41:48.560
cluster. We have our data centers versus just a standalone host, right? A standalone host management

00:41:48.560 --> 00:41:55.760
is obviously very, very different than managing a vSphere environment. So, the OVF template

00:41:55.760 --> 00:42:02.239
finished for deploying, right? We can see all these tasks running. So, back to virtual machines here.

00:42:02.320 --> 00:42:05.840
And I'm going to get them redoing the configuration on that virtual machine.

00:42:06.800 --> 00:42:09.600
All right. So, that's what I wanted to show you. I wanted to show you, you know,

00:42:09.600 --> 00:42:15.840
the different interfaces. I want to show you the difference between the local host configuration

00:42:15.840 --> 00:42:19.679
versus the vSphere client that's used for managing vSphere. And now, it's powering on

00:42:19.679 --> 00:42:27.679
that virtual machine. All right. So, that's what I wanted to show you. I wanted to show you, you