Welcome back to vSphere 8 in the real world. Now we're going to talk about using the host client.
So when you first install ESXi, which we did in our demo, our previous demo, one of the first
things you'll do after you have configured the host and you've gone into the DCUI and you know
given an IP address is you'll probably want to connect to that host and start configuring other
things other than just like say your management network and you know maybe the root password.
You'll connect into the web interface, the host client, and you're going to log into there. You'll
log in again with root and the password you configured for root either during the installation
or if you changed it in the DCUI after installation, whatever you configured there.
And from here you can start troubleshooting any issues with the host that you know maybe not
necessarily connecting to the VM kernel interface because this wouldn't be working if that is down
that's what you do to the DCUI. But then after that you might do some troubleshooting
you know if you're having that kind of storage issues or virtual machine networking if using
different adapters for your virtual machine you might be going to be troubleshooting some things
there. You can perform administrative tasks from here. So maybe you'll create users, you're going
to configure permissions that fit for those users to access different levels of the virtual
machines, things like that. And then any kind of admin privileges you need to assign, right.
So you can access the host by just going to https colon slash slash and either the host
IP address or the name if you have it configured in your DNS. You can connect it by name or by
IP address. So one of the first things you'll usually do after you get your host up and running
you log in is you want to configure a login. Logging is going to be pretty critical to help
you troubleshoot any issues you might have, help you discover if you even have issues sometimes.
So what you'll do is in your host you're going to go to your system, go to your advanced settings.
In your advanced settings you'll do a search for syslog and from there you can configure things
like the rotation of your logs, the size of your log files that you want to use. You can even
change the directory they're stored to. You can also configure a syslog server for your system.
So you know anything logging related would be done through your system and your advanced settings.
And in your system advanced settings as you can see up in the top right you just type in there
your syslog and everything related to syslog would come in. And so here's where you can configure
those advanced settings with the things we just discussed like the size of your log file,
when you're going to rotate your log file, are you going to use a syslog server and what is
the syslog server settings for that. Okay. So this is your advanced settings and again
when you first connect on advanced settings you'll see just hundreds of different things in there.
Just go into your search type in syslog it'll narrow down to things related to your logging.
So post-installation you've installed your ESXi, you have your networking set up,
so what else are you going to do? Besides configuring logging like we just discussed
one of the next things that's very common to do right away will be to set up your networking.
So you might go in and you might configure things like your VM networks, some things like that.
How are you going to want to connect to the system to do things like configure your networking,
configure your storage, start creating virtual machines? Well you can use the vSphere client.
The vSphere client means that you have the system in vCenter and you're going to connect to the
vSphere client to connect to vCenter to then start managing that host. Before you can manage the host
in vCenter you have to add it to vCenter. So you'll log into vCenter and you're going to add
the host to vCenter and then you can start managing it. If you have an Enterprise Plus
license you might connect it to a distributed virtual switch so it gets all its virtual
networking on there. You might want to configure your storage, whatever kind of shared storage
maybe you're using. There's also the host client. So the host client is when you connect to the host
IP address or the host name that resolves to its IP address. And now you're using again the web
client but it's going to be a different client, has a different look and feel to it than the vCenter
client does. And you can do things in there like, again, configure virtual networking, connect it
to storage, create virtual machines, you know, some basic configuration in there. With the vCenter
client you can also do things like create a data center, create a cluster, add the host to vCenter,
add it to the cluster. If you connect to the web client you're just managing that standalone host.
So even if that host is in vCenter you can still use the host client but you won't be able to use
any of the vCenter features. For example, even though the host might be in vCenter, if you use
the host client you can't vMotion or VM to that host or away from that host. You have to get to
the vCenter client in order to do that. So managing our host, as we discussed, there's the VMware
host client, right, which means you're connecting to its IP address. There's the vCenter server. So
vCenter server can actually manage the VM or the host also and you don't have to use the vSphere
client. That sounds kind of redundant. Well, vSphere client manages vCenter so, you know,
aren't they kind of the same thing? I could have a host in vCenter and then I could connect to that
vCenter server and I could actually issue, you know, commands through either Power CLI or through
ESX CLI. There's different ways I can manage the host in vCenter without using the vCenter client.
I could do it programmatically. I can do it through scripts, things like that. So vCenter
can manage the host. The vSphere client can manage the host that's in vCenter also. That's
going to give me a graphical interface to do it through. So ease of access is through a console.
So if I have a VM in my, you know, on my host, I can actually open up a console for that VM
and I could, you know, basically see whatever would be in on that host if I were connecting
like a monitor up to a physical box. All right. That could be accessed through the web clients.
So from vSphere, okay, now mind you, this is not now the web client for the host itself,
the host client. From vSphere, we can remote console into our VMs, right? We can configure
our virtual hardware. We can add devices. We can, you know, manage devices. For example,
if I have a, you know, virtual CD-ROM drive, I can connect an ISO to that. If I have, you know,
virtual NICs on the VM, I can change what port group it's connected to. I can manage the hardware
through there. I can also add devices and I can do things like add a device, like choose what type
of virtual device it's going to emulate. Maybe I add a virtual NIC and I say, okay, what kind
of virtual NIC do I want it to be? I want it to emulate an Intel E1000. I want to use the
VMXNet-3 virtual network adapter. So you can, you know, do settings like that.
You can configure the networking in there. You can connect to data stores. So if you have,
for example, shared storage and you have LUNs already out there with data stores on there,
you can connect to those data stores. If we have raw storage on our hosts, we can also configure
data stores with that local storage as well, right? And then we can also view or modify the
current configurations, policies, alarms, user mappings, meaning what users are able to do and
not able to do. We'll get into all that a lot more. So storage. So once we, you know, have gotten so
far along, we got the host. We are connecting to our host. We want to manage storage. So vSphere
is an excellent way of managing your storage because most of the time in most of your
environments you're going to have, you know, these systems in the vCenter server. You're
going to be connecting to shared storage. And so we can go into our hosts and we can start adding
the data stores. We can configure data stores. Oh, here's my data centers. So basically a data center
might be like, not necessarily have to be, but a lot of times it's like a geographic area, right?
So maybe we have a data center in Houston and we have one in Seattle and we have one in New York.
We'd actually go into vCenter and say, I want to create a data center, one for Seattle, one for
Houston, one for New York. And then in there, I can start creating clusters and my clusters,
you know, might have for however I'm dividing my servers up. Maybe I have certain types of
workloads that I want these servers to run. So I might create a cluster for that. Or maybe it's
for a certain group. Maybe, you know, this department has paid for these servers. These
are their servers. And so I'm going to go in there and create a finance cluster. This kind of depends
on how you're going to do that. What you might also see is based upon hardware. Maybe I have a
cluster for these servers that I bought three years ago and their CPUs aren't compatible with
the brand new servers I bought this year. So I create one cluster for the three years ago CPUs
and another cluster for this year's servers, CPUs, right? So you can create data centers,
you can create clusters, you can then assign permissions. And you can say that these users
over here are able to see the servers in the finance cluster, but they can't make changes
and they cannot see any of the other servers and any of the other clusters. And this other user,
Bob, over here, he's actually the admin for finance and he's able to make changes onto that
cluster. So you can assign permissions. You can configure the message of the day. So when they
log in, they see a banner. Security management, you can configure user accesses and things like
that. You can manage vSAN if you have local storage and these hosts that you want to deploy
with vSAN, you can manage vSAN through here. And health checks. So health checks will basically
tell us if we have software out of date, or if we have configurations that aren't healthy,
or if we have poor performance on – or poor utilization on a certain network adapter or CPU,
or if my vSAN has errors in there or something like that. All that can show up under my health
checks. So managing storage, we talked about creating data centers, right? Talk about
configuring the data center. Capacity. So we can go into our storage and we might have – maybe
we have a LUN that is given to me and it's six terabytes. I can decide if I want to deploy
a data store that takes up the entire LUN, the whole six terabytes, or maybe I only need a small
LUN for a certain cluster for a small number of VMs, so I'm only going to use one terabyte or
750 gigs or something like that. Storage control. So again, we talked about storage IO control.
We can configure storage IO control if we have licenses for that. We can configure to make sure
that VMs don't overutilize the amount of IO to storage that they should. We don't want one VM,
the term noisy neighbor has been thrown around quite a bit online, a noisy neighbor VM using a
lot of IO and kind of drowning out other VMs. Storage IO control makes sure that everything's
done kind of evenly and equally. We can also say this VM over here is pretty important and we want
to give it a higher priority. We want to give it more access to storage. So it actually does get
more IO. We can say how much more. We can control the amount of additional IO it gets compared to
the other VMs. So space reclamation. If we have a storage array that supports the storage APIs
for VMware, what can actually happen is you'll see like virtual disks, for example, can start
growing, growing, growing. And maybe you go in like, oh wow, we put a bunch of data on here. We
don't need this temporary data there anymore. Let's delete all this temporary data. We delete
500 gigs of data off of there. But your VMDK file doesn't get any smaller, right? If it's a thin
provision VMDK, it will get bigger, but it doesn't get any smaller. Well, actually what you can do
is you can have your systems, your storage arrays communicating with vCenter and realize that,
you know what, we can get rid of all this space here. We can free up this space. A LUN might be
set to grow and shrink also. And you delete the VMDK off the LUN, but the LUN doesn't shrink back
down. So we can actually have it go in and zeroize information. It can go through and zero and
reclaim space that has been freed up. And so that space is now presented back to the storage array
as being available for another VM or another host or some other function on that storage array.
Storage and CPU. So time to manage networking. So in your network, you might want to monitor
the activities that's going on. There actually is performance charts for, you know, CPU,
for storage, for memory, and for your networking. So you can actually go in there and look at
physical adapters and see how utilized and how much traffic is being, you know, sent,
how much is being received. You can also look at it on the VM level. You can see how much traffic
VMs are sending and how much traffic VMs are receiving as well, right? So you can manage
the performance or monitor performance through your performance charts. You can manage permissions.
Again, we've discussed permissions quite a bit. Same thing. You can say who can configure virtual
switches or who can't configure switches and who can change VMs, you know, virtual network adapter
settings, things like that. You can move your VMs to other networks. So what can happen is you
have your virtual NIC and your virtual NIC is attached to a port group. You can go in and
change it to a different port group. Just keep in mind that moving to a different port group often
means you put it onto a different VLAN. Different VLAN means you need to re-IP that virtual machine,
unless for some reason you have two different VLANs that are using the same IP subnet range and
then you've probably got some other issues going on that you need to address there.
You can specify which VMs are going to be on what networks, and you can go in and actually
monitor traffic, and then you can say, okay, I have these physical adapters on this virtual switch,
and you can specify that you want this one to be active, you want this one to be standby,
maybe you want them both to be active, and then if you do want them both active,
you can say how you want the VMs assigned to the different adapters.
What will happen is a VM will be some kind of load balancing algorithm. You can say I want to
be based on an IP hash of the source and destination IP. I want to be based upon the virtual port on
the switch the virtual machine connects to. So this port's going to connect to the first NIC,
and the next virtual port connects to the second NIC. You can balance them that way.
So there's a lot of different configurations on your virtual networking that you'll want to
configure, and how you configure that can have an impact on how your VMs are formed.
If you have multiple adapters, but only one is set to active, you might find that your performance
is not as good because maybe you're overloading that adapter. If you made one of the standby
adapters also active, then you have to configure the switch so that the ports those NICs connect on
are set for a lag, but not a dynamic lag for a static lag, and then they can balance the load
for the VMs across those adapters. This is talking about if you're upgrading our ESXi 7
systems to ESXi 8, and we're running certain Dell PowerEdge servers. If we use the Dell ISO for
version 7, then there is going to be drivers installed that have been depreciated, and those
depreciated drivers don't have a version 8 to go to, and so the installation fails. So what you'll
need to do is go in and basically just SSH the host and remove the bad drivers, or bad drivers
is the last right word, the depreciated drivers, the ones that they're no longer using, so that
way 8 doesn't try to upgrade that and say I don't have a version for that and fail. We've removed it
from version 7, and the version 8 upgrade goes smoothly. I've seen that before with HP devices
too, going from like 6.5 to 7 and things like that. It's a pretty common issue to have.
So some best practices. Basically, one of the things to keep in mind when you're doing a virtual
environment is virtual and physical are very different. When you buy physical servers, you
normally buy the most your budget is going to afford you. You want the most CPU you can afford,
the most RAM you can afford, the fastest and biggest hard drives you can afford. When you're
doing virtual environments, you want to kind of do the exact opposite. You want to go slow,
opposite. You want to go sparingly. Give it the minimal hardware that it needs to perform its job
at the level you want it to. If the machine can do its job and do it well, the virtual machine
can do it well with two virtual CPUs, don't give it 8. If it only needs 4 gigs of RAM to run its
workload and run it effectively, again, don't give it 8, don't give it 12, don't give it 24 gigs.
Give it the minimal resources it needs because what happens is that all these VMs using more
resources than they need, it also creates overhead. And overhead is something that
it's additional work on top of the host that it takes to run those virtual machines.
If the VM has too many virtual CPUs, the host can say, well, we're not scheduling these,
so I'm going to schedule them for another VM someplace else. But that overhead that it takes
to manage that doesn't go away. That does not decrease. The overhead never gets redeemed by
the host because you're not using that resource. So you'll find also that it's hard for the host
to schedule a lot of VMs with a lot of virtual CPUs that greatly exceed the number of physical
cores or virtual cores that the host has in it. There's a scheduling service. The scheduling
service will say, this VM has four virtual CPUs. I only need to run two threads. I only need
two cores. But the VM has four virtual CPUs. I have to schedule all four together. I can't
schedule only two. So if the VM has eight, then it has to schedule all eight at once.
And if you're only needing to run two threads, the other six cores are assigned, but they're not
doing any work. And other VMs that could be using those cores don't have access to them.
So assigning too many virtual CPUs can negatively impact the performance of your
virtual environment if they're not necessary. Same thing with assigning too much RAM.
There's a lot of overhead involved with managing that. And as you know, a Windows system
maybe only needs four, but you gave it eight, it's going to suck up eight. And it's going to
sit in physical RAM at eight. And if you were to reduce that VMs down to four,
you'd find the performance all of a sudden is fine, is acceptable, and the other VMs are
performing better as well. So make sure that you're sizing your VMs appropriately for the
workloads you're running. Start small. It's really easy to add. It's not always as easy
to take away because users get used to a certain level of performance. And as you're taking things
away, they might see a small hit, which maybe is within your SLA, but it's not what they're used to
and they're going to complain. All right. So some of the best practices are just use the resource
you need. Use the minimal amount that you need to get the work done properly. Also, when you're
sizing your hosts, having multiple medium-sized hosts is often better than a smaller number of
very large hosts. Because if you have, let's say you have three very large, beefy hosts with
a terabyte of RAM and just super fast gold-level Intel Xeon processor CPUs and all that kind of
stuff, and one of those hosts fails, it may take down a large number of VMs. Where if we had taken
that same money and scaled out and had maybe six hosts or eight hosts or nine hosts, and one fails,
I lost a smaller number of VMs. Now, HA should restart those VMs for me, but the impact to the
users while that restart happens is going to be a lot less with moderate-sized, more hosts.
Right? Now, there are other things to consider if you're in, for example, if you're in a colo location
and you're paying for rack space and you have to get a second rack, that makes it more expensive.
Power is questionable. Maybe that might take up more power that way. The bigger CPUs take a lot
more power. The smaller ones kind of even that out sometimes. So there's a lot of considerations
in there, but scaling out is usually a good idea. Having moderate-sized hosts that you can scale out
for failure is sometimes a good idea. But of course, your environment might really require
big, beefy hosts that can run a smaller number of big VMs. Then you need large hosts that can
run those big VMs. There's always going to be conversations that make things valid one way
or the other. You should look at your environment and just take a serious look at what would work
best for you and don't just automatically assume get the biggest host you can, because that's not
always the best use of your resources. Okay? So some memory best practices, same kind of thing.
Size appropriately. If you are committing more memory than is needed, you might also start
running into issues where you've over-allocated RAM. That increases the overhead, as we mentioned
before, on the host. And what starts happening is the host is going to start doing some things to
try and manage the memory of those VMs to make sure it can allocate all that it needs. So one
thing it does is page sharing. By default, page sharing is turned off. It used to be on by default.
It was a paper written several years back saying that it might be a security vulnerability. So by
default, transparent page sharing has been turned off by default. But you can go in there and turn
it back on and fill an option. And what that basically means is that if I'm running five VMs
and they're all running the exact same version of Windows Server 2000 and 2016 with the same patch
levels and everything, there's probably a lot of pages that are exactly the same from the operating
system, for example, on all the hosts. So rather than write those pages five times for five VMs,
I write it once and I point all five VMs to that same physical page in memory. All right, that's
transparent page sharing. By default, that is turned off. What ballooning is is that if a VM
is using a lot of physical RAM, there's a driver with VMware Tools. You have to have VMware Tools
installed in order for ballooning to work. And you always want VMware Tools installed anyway for
performance reasons. The host can trigger the balloon driver in a VM. And that balloon driver,
all it does is start eating up RAM. It just eats up a bunch of RAM. And the host can see the RAM
that's being eaten up by the balloon driver. And so what's happening is the host, I'm sorry,
the virtual machine that's launching that balloon driver is starting to write what was in that RAM
to its page file. It knows what's more important or what's least important to have in RAM.
And the less important information gets written to its page file in the VM. The host sees the
balloon driver and says, okay, that's balloon driver, so I don't actually have to put that into
physical RAM. That frees up physical RAM on the host to use for other VMs. And then the virtual
machine will start taking things from the page file and loading it back in RAM. You might start
seeing the RAM fill up again. Or maybe it's stale information that's been sitting there for a while
and isn't going to be accessed again for a while. And we just, you know, maybe solve a problem.
Memory compression is basically where the hypervisor starts compressing
information in pages of RAM to try and make it smaller so we can free up RAM.
That obviously is very CPU intensive. Then there's the host swap. So, this traditional regular host
swap means that we can take what's in RAM for a VM. Maybe the balloon driver's already tried
its thing and all these different things of RAM. And it starts page into that VM's. Each VM will
have their own page file, right? So, we can't start taking things that's for a, you know, VM1
and put it into VM1's page file. The VM thing is actually in RAM. But the host knows that,
well, when the VM asks for this page in memory, I've written that to a page file. So, you see,
that's why the balloon driver is better. Because the balloon driver lets the VM pick what to page.
When the host starts writing things from physical RAM to the VM's page file on the
VMFS data store, the host doesn't know what's important or not important to the VM.
It's picking for it. So, you're better off using the balloon driver. But if we tried that,
still need more RAM. We tried compression. We still need more RAM. We can use the VM's page file.
And then this regular, you know, regular host level swapping just for their host's own,
you know, swap file for its own functionality is another option for
the host has to try to free up RAM in its system.
So, for storage, if you're using shared storage, it's always a good idea to try and use a storage
vendor that supports the vStorage APIs for array integration. So, VAI. Basically, it's APIs that
the host can use to communicate with the storage array to do things like zero out, you know,
unused pages, unused blocks on a disk. It also can use it to say, I need to write a new VMDK
file, and that VMDK file is going to be thick provision eager zeroed. So, I need to write a
bunch of zeros. The host could just start saying, write 0, 0, 0, 0, 0, 0, you know, until it's
filled up this VMDK file. Or it can say, create a VMDK file and fill it full of zeros. And then it
just hands it off to the storage array. The storage array does it. The host can also say, I need to
move a VM from this LUN, from this datastore, to this datastore. And if it's on one storage array,
the host could start reading and writing, you know, over the network. Or it could tell the
storage array, move that VM over there from here to here. And just hand off the work to the storage
array. It can monitor it. And when it's done, the storage array says this task is complete.
And the host can tell you your storage vMotion is complete. So, basically, it allows the host
to hand off jobs to the storage array so that, one, the host isn't doing the work. It's not taking
up resources on the host. It's not taking up resources over the network. And the storage
array can do it internally much faster than the host can do it over the network. So, that's
the APIs. And those are a really, really good idea. Most storage vendors, especially if they are
any kind of VMware partner, obviously, support the APIs. So, for virtual disks, there's obviously
some different ways we can create virtual disks for our virtual machines that will be on that
storage. We have independent persistent disks. And those were considered for best for performance.
Okay? So, with an independent persistent disk, basically, what's going to happen is,
excuse me, we can create a VM and we can, you know, run it. And then when we're done,
we can shut it down. And when we turn it on again, it's like it was we turned on the first time.
Whatever was happening and done to it doesn't take up, isn't saved. Nothing's saved on that disk.
Okay? Independent non-persistent has review logs. So, basically, what that is, if you take a
snapshot on that, it actually snapshots. With the persistent disk, there's snapshots don't
happen. Nothing really happens on it. Dependent disks, those are actually just our regular
everyday disk. That's the default. A dependent disk is a regular disk. So, when you write to
the disk, the changes get written to the disk. So, if you create a new VM, you install an OS,
you save a file to it, the file gets saved. If you take a snapshot, the snapshot file gets created.
All the changes from that point forward get saved to that difference file. That's that snapshot.
And then you can say if you want to, you know, just basically save the snapshot,
you want to delete it and save the state, it all gets merged into one VMDK file. Or you can say
delete it and roll back the way it was before. All right? So, dependent disks are the default
disks that you always use. Independent persistent or non-persistent basically means that we don't
want changes to be made, right? And we don't want to be using snapshots on them.
So, disk types. There's two disk types when you create a new VMDK file. There's thick provisioned
and there's thin provisioned. A thin provisioned disk means that it basically just creates a small
file that kind of a placeholder for that virtual disk. And as you write to it, the file is going
to grow. It grows in blocks. The thing about that is that growing actually gives you a small
performance hit every time you have to grow the file. The advantage of it is that if it's a,
say, 500 gig VMDK but it's thin provisioned and you're only using 10 gigs, it's only 10 gigs in
size. It's not 500 gigs in size. So, thin provisioned is a very efficient way of using space,
but it's not as good for performance reasons. Then there's thick provisioned. If you thick
provision a disk and you say it's 500 gigs when you first create it and there's nothing in there,
it's 500 gigs. The whole amount of space is allocated all at once. Then the question is,
do you want it to be lazy zeroed or do you want to be eager zeroed? If you make it thick provisioned
and eager zeroed, the system goes and it writes zeros to all the blocks in that virtual disk and
zero out the whole thing before it says it's done and it's ready for use. So, that can take a while.
It might take a while to create that VMDK file. And it obviously is going to create some overhead
on the storage arrays and work around the network. Lazy zeroed says create the 500 gig disk,
but what happens is the first time you write to a block, it zeros out the block. Then it writes
your data. And if you go to write to another block, it zeros out that block, and then it
writes your data. A block has to be zeroed out the first time it's written to. So, it can either be
eager zeroed, written out in advance, or lazy zeroed, written zeroed out as you use it.
Performance-wise, obviously, the eager zeroed is going to give you the very best performance.
And lazy zeroed will give you the next best because it doesn't have to grow the file,
but it does have to zero it. Thin provision is going to give you the least good performance,
the worst performance, because you have to grow the file and zero out the blocks as you go along.
So, I think the default is thick provision lazy zeroed for a lot of situations.
If you have, again, the storage API and you do choose to do a thick provision eager zeroed,
it happens, actually, pretty quick because it hands it off to the storage array. The storage
array says, yep, I got that done, and the system can go on with what it's doing while it zeros out
that VMDK file. All right. So, before we wrap up this lesson, let's go ahead and do a quick demo
where I'll show you what the vSphere client and the web management client for the ESXi host looks
like. So, here we have the host client, the management client for the vSphere ESXi host
itself. So, I'm going to go ahead and log in here. Username is root and the password.
So, here, when we log into the vSphere host, you'll see the vSphere host is actually a little
different. The vSphere client is a little different than for the host itself. So, we can
see if we have any virtual machines created on this host, any storage that might be configured on
this host, right? Under storage, we can see if we have data stores. All right. We have one data
store, which is just on local storage. If we have any devices, let's go back to here and look at
devices, and you can see we have a CD-ROM drive, and we have that local disk on this host here
configured. Under networking, we have port groups. We have some virtual switches, and actually,
virtual switches are the highest level, and then you have port groups,
right, on those virtual switches. So, if we were to go to the switch itself,
we would see we have a management port group on here. We have that vMotion port group on here,
and if we go back to networking and port groups, you see we have management, we have vMotion,
and then on our virtual switch, we have a storage virtual switch, and we have a
VMkernel port that is configured. If I go to my VMkernel port,
I have an iSCSI vMkernel adapter. Let's go to edit the settings,
and you'll see it's on that iSCSI port group, right? So,
we have our – I'm sorry, storage – I'm sorry. The name of the port group was iSCSI,
and it's on the storage virtual switch, storage port group, right? So, go ahead and go back to
networking, go back to our port groups. We have our iSCSI port group on there. All right,
and then we have our storage virtual switch.
Then, under networking, we also have our physical NICs. So, we can see all of our physical adapters
and we can see, you know, the – now, this driver, this is because this host is actually a virtual
machine, and so this is the adapter that's installed on it, so it's the driver that's being used,
our MAC address that's on there. We can also look at switches,
and on the switch, we can see what physical adapters are on this virtual switch,
we can go back to our physical NICs, see? And then, we can go to our storage,
and we have one NIC attached to that. So, there's actually one NIC that's currently,
one physical adapter on this host that's not assigned to a virtual switch, all right?
Now, we're going to get into this in a lot more depth in a later lesson where we'll actually go
into the switch and we'll look at the settings on the switch, and we'll talk about the uplinks.
We're going to talk about what the link discovery and security, what all these different things
mean. So, I just want to do a quick walkthrough and show you this interface currently.
So, we're going to go ahead and go ahead and get started. So, we're going to go ahead and
what all these different things mean. So, I just want to do a quick walkthrough and show you
this interface currently, right? On the host itself, the two main things you're going to,
you know, do other than maybe have virtual machines is you'll probably configure the
networking and you'll configure storage if you have any storage you need to configure, right?
If we go to TCPIP stacks, we can see, like, we have an IP address configured on this guy here.
Under firewall rules, you can see if you have any services enabled in the firewall policy open.
DHCP is open on here. If I scroll down, you should have an iSCSI. Let's see.
Software iSCSI client, right? That is enabled. That policy is enabled. SSH is enabled. So,
that's your firewall rules there. All right. And we don't have any virtual machines currently
on this host. All right. Now, also, the client for vCenter, it does a lot more.
It's actually really different. So, our vCenter IP address is this guy.
So, let's just go ahead and log in there. Now, launch our vSphere client.
So, I'll log in. So, here, you can see,
here we have our vCenter. Here we have a data center for our Houston data center,
and we have a data center configured for our LA data center. We have a cluster configured in here.
Notice it's really different, right? So, here, we have a different place to go to look at data
stores. We have a different place to go to look at networks. And even though here we have networks,
if we want to configure our networks, we're going to go to configuration. And then from here,
we could go in and configure, you know, different types of services and things like that, right?
If I were to add a host to this, let's just say we add this host in there for right now.
So, we're going to say that's the host we're going to add. We're okay with that
SHA-1 thumbprint, SHA-1 thumbprint.
Give that a moment to come the rest of the way in. It takes a moment.
So, here, we can see the tasks are going on. You can see the tasks that have already been completed,
right? And you can see the ones that are still in progress.
You could also look, for example, on that cluster. You can go to monitor.
So, there's the host that's already added. You can see tasks listed here that were related to
you can see tasks listed here that were related to that cluster.
Here we have a host, right, added. We're going to go ahead and take it out of maintenance mode.
All right. And so, we've really got networks over here. You see we have the networks that
were on that host on here. Let's go ahead and just give us some more room. We can go to configure
and here's virtual switches. There's the management, right, the vMotion one we saw before.
Here is that storage virtual switch. Here's the iSCSI
port group and our vMkernel port for our iSCSI, right? So, the adapters that are on there,
right, with adapters are mapped to the switch. So, quite a bit on there. Notice all of a sudden now
we've got a virtual machine. Because we are adding a host to a cluster, it deploys this
virtual machine. It deploys two or three of them into the cluster and these are actually
completely managed by vSphere. We don't do anything with these. We don't start them up.
We don't shut them down. We don't do anything with them. And vSphere is going to manage these
virtual machines, which are used for managing the cluster for, you know, seeing up and down
times and things like that. So, it's still doing its thing. You can see it's deploying
that virtual machine still. That task is not complete, which is why it's still powered off.
So, the real thing I wanted to show you is just how different the host interface is
compared to vCenter, right? Whereas on the host, we have a place to go for networking and we can
see our network and configure our network and all that kind of stuff from here. But in vSphere,
we have one place we can go and just view our networking, but we also, under configuration,
can go in and configure virtual switches, configure VM kernel adapters, manage our
physical adapters, TCP IP configuration. We have configurations for virtual machines, the system,
right? A lot of different options all under configuration. We're going to go into quite
a bit of all this stuff as we get into other adapters. We'll have storage. We'll talk about
configuring storage when we get into those lessons. But right now, I just wanted to show you
that this is what you're going to do to manage vSphere. So, we had multiple hosts. We have our
cluster. We have our data centers versus just a standalone host, right? A standalone host management
is obviously very, very different than managing a vSphere environment. So, the OVF template
finished for deploying, right? We can see all these tasks running. So, back to virtual machines here.
And I'm going to get them redoing the configuration on that virtual machine.
All right. So, that's what I wanted to show you. I wanted to show you, you know,
the different interfaces. I want to show you the difference between the local host configuration
versus the vSphere client that's used for managing vSphere. And now, it's powering on
that virtual machine. All right. So, that's what I wanted to show you. I wanted to show you, you