Welcome to VMware vSphere VCP 2024 Data Center Virtualization.
We're going to start with some virtualization basics.
So first thing we do is compare physical computing to what you might see with virtualization.
With physical computing, you have one server and one server often would mean one service.
So we might have a server and that server is going to run an Exchange server,
it's going to run a SQL server, or it's going to run an Active Directory, Directory Services services, things like that.
So if we're running a physical environment, a physical computer, one server is dedicated to one service very often.
It doesn't always have to be that way. You can add things together.
Usually it's best practice not to.
You want to have some isolation dedication so you don't have one resource overwhelming another,
or you don't want to have one service conflicting and causing problems with another,
or a service gets updated by its vendor and then starts causing conflicts with another service that hasn't been updated yet or something like that.
So usually when we have a physical environment, we have a lot of servers running a lot of different services, one each,
and not a lot is heavily utilized. You might find that if you were to average out everything in your data center,
maybe you're running out by 5% or 7%, 8% utilization a lot of times.
So with a physical environment without virtualization, you'll find that you have a lot of resources,
a lot of purchases, a lot of servers, and not a lot of utilization, not a lot of bang for your buck, so to speak.
And with virtualization, you'll see that we can greatly reduce that footprint.
So some of the components of a physical server. Physical servers are going to have the physical hardware.
They're going to have things like RAM, CPU, hard disk networking.
Then you're going to have an operating system installed on that physical computer,
and then that operating system will have sole control over the CPU, the memory, the storage, all that kind of stuff, right?
So some common operating systems for physical servers in a data center will be, you know,
Windows Server or some version of Linux, for example, like Red Hat.
Now with virtualization, all of a sudden, we're creating these containers, these virtualized containers on this physical box.
So the operating system in our VMware vSphere environment will be ESXi.
That's what we're going to install on that bare metal.
But then that hypervisor, the ESXi, is going to allow us to create these containers that will virtualize hardware
so that we can have multiple operating systems installed on top of that ESXi host.
So we might have Windows. We might have Windows 2016, Windows 2019, Windows 2022.
We might have Red Hat Linux running on the same machine as those Windows servers,
as well as, you know, SUSE or Ubuntu or something like that, Debian.
So we can mix all these different operating systems together because they're all self-contained.
One does not see the other.
The only way that one could impact the other is if one started using a lot of resources,
maybe starts using a lot of network bandwidth or a lot of CPU,
and causing the other virtual machines to not have that level of access to the resources they need.
But there are also ways to prevent that.
We can, you know, create limits.
We can create resource pools.
We can throttle bandwidth on the network interfaces and say that we only are going to let a virtual machine use,
you know, half of one core or, you know, two cores max or however you want to configure that.
So that way, virtual machines don't impact others.
But the great thing is we can patch one of our virtual machines, and we don't have to patch the other.
So we have on one box, maybe we have an Exchange server running.
We have an Active Directory Directory Services server running.
Maybe we have a Linux box running, a database.
And we can say, okay, we're going to upgrade Exchange.
And we're going to actually upgrade the OS to 2022, but we're going to leave this other server over here on 2019.
And the Red Hat box, we're not going to patch that one at all right now.
We're going to get to that one next week or next month or whatever.
And they don't impact the others, right?
They all are running isolated.
So there's two types of hypervisors.
There's what's called Type 1 hypervisor and a Type 2.
ESXi, which is kind of the core OS for a vSphere, a VMware vSphere environment, is what we refer to as a bare metal hypervisor.
It's a Type 1 hypervisor.
There's also a Type 2.
With a Type 2, you install a hypervisor on top of an operating system.
So an example of that would be VMware Workstation, where maybe we're running Windows.
And on top of Windows, we want to install VMware Workstation.
And so that's a Type 2 hypervisor because it doesn't get installed on bare metal.
It does work with another operating system below that.
So oftentimes in a virtual environment, what we refer to that server, the one that is doing the virtualization.
So in this example, our ESXi host, we refer to that as a host.
So if you're talking to somebody about your data center, you might say, yeah, we have, you know, 100 hosts.
And those 100 hosts are running 800 virtual machines or 1,200 virtual machines.
So the VMs, you might have 1,200 operating systems running.
You might have, you know, multiple different versions of Windows and Linux like we mentioned.
But they're running on 100 physical boxes.
And maybe those boxes are running ESXi.
So the ESXi boxes are the hosts that are running the guests' virtual machines, okay?
Also in a virtual environment, you want some kind of software that allows you to manage those hosts.
I don't want to log into this host and manage the VMs that are on there, then log out and log into another one and manage those ones.
I want to be able to look at my entire infrastructure in one view, see all the hosts that are in my infrastructure,
see all the VMs on all those hosts that are in my infrastructure, and manage those.
I want to be able to say, okay, these, you know, 10 hosts here, these are going to be a cluster.
And in this cluster, we're going to create a resource pool that says how much of the resources for these 10 hosts,
these 30 VMs, or maybe just these three VMs are in that one resource pool, how much they can use, right?
And so by using a resource pool, we can carve up a cluster.
A cluster is a grouping of hosts.
And we can say how much resource these VMs are either going to be guaranteed to have or limited to, or both.
We can say we're guaranteed they have this much resource.
So the other VMs can't overwhelm them.
These ones are really important.
We're going to make sure they have, you know, at least, you know, 10% of the resource pool CPU processing power.
But they can't use more than 20.
You might say something like that, okay?
So the tool in a vSphere environment for doing all that management of all those hosts and all the VMs and things like that is going to be your vCenter server.
So really the core two basic pieces you're going to have in a vSphere environment will be your host, ESXi, and your management tool, which will be your vCenter server.
So that is really kind of the basic there.
Now, there are a lot of things you can add in to help you manage this environment.
You can use things for managing or making your network far more robust, like NSX.
Maybe you want to do virtual desktop hosting, so you might get Horizon.
There's a lot of different tools you can use, you know, tools for reporting, you know, things like that.
But the basic bare bone, you know, data center environment, you're going to have your ESXi hosts, and you're going to have a vCenter server.
So on those hosts, when we want to configure networking, so we want to say, all right, this host, this physical box that's running these 30 VMs on it, for example, it has two network cards.
Maybe it has two 10-gig network cards in there, and those two 10-gig network cards are going to allow access for these 30 VMs.
But not all the VMs are going to be on the same VLAN.
On a typical physical environment, my server is going to live on a VLAN.
My Exchange servers live on VLAN 50, okay?
And my Active Directory Services, you know, VMs, maybe they're also on VLAN 50.
All my servers are on VLAN 50.
But maybe I say my Windows boxes are going to be on VLAN 50, and my Linux boxes are going to be on VLAN 60.
Or maybe I say my Exchange servers are on 50, and my Active Directory Services are going to be on 51, and my file and print servers are on 52.
I really segment them out because I'm running thousands of virtual machines.
And so because I have so many VMs, I'm going to really start isolating down what lives on each network so that when I see an IP address, I know, oh, that is, you know, 172.16.50.
That's my VLAN 50.
And so I know that is a Exchange server or something like that, right?
So how do we take two network cards and run three or four or 10 or 15 different VLANs on two network cards?
On an ESXi host, I create a virtual switch, or maybe I can create multiple virtual switches.
If I had in my host, instead of having two network cards, maybe I had 10 network cards.
Again, that would be a lot.
But maybe I have 10 network cards.
And I'm going to say on this virtual switch, I'm going to let these six network cards be on this virtual switch.
And on this other second virtual switch, I'm going to have these four network cards be on that one.
You can divide them however you want.
I could have three, you know, virtual switches, and I could say I have these three on this one and these three on this one and these four on that one or something like that.
And maybe the reason why I have two virtual switches is all my VMs are on one virtual switch.
And on my second virtual switch, I have my iSCSI storage.
Or maybe I have three virtual switches, and my VMs live on one virtual switch, and my iSCSI storage is on my second virtual switch.
And my third virtual switch has, like, my VM kernel ports.
I have a VM kernel port for management and another VM kernel port for things like vMotion and things like that.
And on my iSCSI virtual switch for my virtual storage, I need a VM kernel port also there that connects to my iSCSI storage, too.
So you can see we can take those virtual switches and we can divide up our physical NICs on there.
But again, if I have one virtual switch and I'm running 10 VLANs, how do I say what VLANs are, you know, what and what VMs connect to what?
On a virtual switch, I can create what's called a port group.
So I can divide up my virtual networking in my host with virtual switches.
I can divide up those virtual switches into what they call port groups.
And a port group is going to basically kind of be analogous with a VLAN, okay?
It doesn't have to be.
It's not exactly, you know, one for one.
But oftentimes, the reason why we create port groups on a virtual switch is so we can create different VLANs with different VLAN tags.
So I might go in and say, okay, I'm going to create this VLAN 50 for my exchange servers.
And I'm going to create another port group that is for file and print servers, and that's VLAN 51.
And another port group for my domain controllers, and that's VLAN 52.
I'm not sure what examples I said before.
But, you know, basically, I can create port groups for different types of VMs and then put different VLAN tags on there.
Maybe I have my Linux boxes that are running a certain database.
So I might have my Linux boxes be on VLAN 60 through 69, and databases are on VLAN 60.
And my Linux boxes that are running, you know, web applications are on VLAN 61, okay?
So I can look at these different things again, 172, 16, 61.
Oh, that's a Linux box and it's running a web application, okay?
That might be how I decided to break things up.
You don't always see things divided up so cleanly like that where, you know, you just look at an IP address and know exactly what it is.
But wouldn't it be fantastic if we actually did design our data centers that cleanly and stuck to it?
That's strictly.
So a virtual switch is a way of breaking up the networking on a host.
And we can assign physical NICs to a virtual switch and then a port group to that.
But the problem with a virtual switch is, in my example, maybe I have in my data center 100 hosts.
With a regular virtual switch, I have to go to every host, create those virtual switches,
and create those port groups named exactly the same on all the hosts.
If the name isn't exactly the same, including maybe I want to call this port group Exchange.
I did capital E-X-C-H-A-N-G-E, Exchange.
But on the next one, I did a lowercase e.
Guess what?
So the two hosts, those are different port group names.
And so if a VM has a connection with a virtual NIC to that Exchange port group with a capital E and I want to vMotion it to another host,
I want to move that VM to another host with that same port group, but it's a lowercase e,
it'll say that's not the same.
I can't vMotion over there.
Or I have to go in there and select the different port groups I wanted to move to and things like that.
It gets to be cumbersome.
DRS will have a hard time working in that kind of environment.
HA will have a hard time working in that kind of environment.
So they need to be named exactly the same.
So you can see creating virtual switches, just regular virtual switches, when you have a large number of hosts,
becomes very cumbersome and you have to make sure you are typing things meticulously and the VLANs have to be meticulously the same.
So what VMware came out with is what they call a distributed switch.
So now, again, I go back to vCenter.
This switch is created in vCenter, not on the host.
A regular virtual switch, I can go into vCenter and connect to my host and say create my virtual switch,
then go to the next host and create my virtual switch.
But with a distributed switch, I can go to my networking option and create a distributed switch.
And I define the switch.
I define my exchange port group on there and I give it VLAN 50.
And I create my ADDS port group and I give it VLAN 51 and so on.
Then I say I want this virtual switch and these port groups I created to go to and then live on all of these hosts.
Maybe I say all 100.
Or maybe I say, well, exchange and Active Directory and all these things are only going to live on this cluster of hosts.
So I only assign to those 10 or 20 or 30, however many are in those clusters, to those hosts.
And now they automatically all have the same virtual switches created on them, distributed virtual switches,
the same port groups, named exactly the same with the exact same VLANs configured,
and they have the same network, physical network card configuration.
Because I can say on this virtual switch, I want it to have three uplinks.
And then when I assign it to host, it'll say, okay, well, which physical NICs do you want to go to uplink one,
to uplink two, uplink three on the next host?
Which physical NIC do you want to go to uplink one, uplink two, uplink three?
And you can do that for all of them.
So now when I make changes and I add another port group, it goes to all the hosts.
If I change the VLAN tag on one of the port groups, it goes to all the hosts automatically.
I don't have to manage those hosts one at a time and make all those changes.
So a vSphere distributed switch is a centrally managed switch that all my hosts in my vSphere environment potentially can use.
Now, they don't have to use it.
I can pick and choose which one to use.
I can create a different distributed virtual switch and assign it to different hosts if I wanted to.
Or to the same host.
My hosts have 10 NICs.
This first distributed virtual switch is only using three.
The next distributed virtual switch goes to the same 30 hosts maybe, but uses different NICs.
And I create another one that goes to a different set of hosts, a different 10 or 20 or 30 hosts.
So virtual switches are defined on each host one by one.
And a vSphere distributed switch is going to be defined in vCenter and then attached or assigned to the host I choose.
Okay.
So that's the networking part of some basic virtualization.
Now, if this sounds like I'm just kind of glossing over it, I am.
This is an introductory lesson.
So we're going to get into a lot more depth onto how to configure these things in later lessons, later chapters throughout the course.
So storage.
There's different types of storage you can configure in a vSphere environment.
There is local storage.
So there's storage that is, you know, disks in this host.
And I'm going to put on the disks that are in this host, I'm going to put my VMs on there.
But the problem with that is those VMs are on this host.
If this host goes down, if it catches fire, those VMs are there.
And so now they're gone, right?
I can't just start them up from someplace else because they lived on the storage on that host, which is no longer available because the host caught fire.
The other option would be a SAN, right?
So the nice thing about a SAN, which is a storage area network, right?
So storage area network kind of refers to an entire network.
This is going to be a device that lives on that network.
So this device is going to be either fiber channel or it's going to be iSCSI.
And I'm going to be able to connect my hosts to this storage device.
And the storage device is going to have, for example, a LUN carved out on it.
And multiple hosts can point to that same LUN and see that same LUN.
So now the VMs that are on there are accessible to all the hosts that are connected to and, you know, in that cluster and connected to that LUN and so forth.
Now, only one host can run a VM at a time.
So I'm not trying to suggest that, you know, multiple hosts can all access the same VM.
But if my host 1 is running VMA and everything's going great, VMA is running, doing its job, and host 1 catches fire and it's gone and we can't connect to it anymore,
host 2 can then say, oh, look it, host 1's gone down.
That's what HA is, high availability.
Host 1 has gone down and it was running VMA.
I know VMA lives over here.
I'm going to connect to the files that were for VMA and start up VMA.
Now, HA is more complicated than that, and we'll discuss that when we get into that lesson.
But for right now, just know another host can connect to that same storage, find that VM, and start that VM up.
And maybe I'm down for, you know, a minute or two or something like that if a host has a catastrophic failure.
There's also DRS so that, let's say, again, host 1 is running VM A, B, C, and D, and all of a sudden these VMs are really working hard and they're using a lot of network or a lot of CPU.
And host 1 can't keep up with the load from all these VMs and all the heavy lifting they're doing.
DRS, distributed resource scheduler, can just say, well, I'm going to move a VM over to host 2.
And host 2 can see that same storage because it's on the network, right?
It's on the SAN.
And it just moves it over while it's running and users don't even see a thing.
They don't even notice it's been moved.
They don't notice an impact in performance.
They don't notice, you know, a loss of connectivity.
The only thing that might happen is it might not be as resource constrained anymore so it might be responding a little faster.
And that way performance might be better.
That's the hope anyway, right?
So by having a SAN and that shared storage versus just local storage, we have different DR capabilities.
We have different HA capabilities.
We just have better resource utilization.
Maybe I don't have a problem with my resources at all, but I need a patch host A.
Host A is kind of out of date.
VMware released a new critical security patch that I need to get pushed out.
I can just move all the VMs from host 1 to host 2, patch host 1, get it all up to date and current and, you know, no longer security vulnerability.
And then when it's done, it comes out of maintenance mode.
I can move all the VMs off of host 2 over to host 1, and I can patch host 2.
And, you know, if I had five hosts, I can divide them up amongst the five, you know, the four that are remaining, and patch that one.
Then I can move VMs back around and evacuate host 3 to the other host and patch that one.
So having shared storage like a SAN, either an iSCSI or a Fibre Channel SAN, allows me a lot of functionality.
Again, things like, you know, DR capabilities, backup capabilities, DRS capabilities, you know, for resource scheduling, HA capabilities.
Now somewhat sort of newer, but it's been out for quite a while now actually, functionality is what they call vSAN.
So with vSAN, we're going back to the disks that are on the host.
All the hosts have local storage on them.
And maybe they have 15 or 20 or 30, or it depends on how big of a host you need, how much storage you need, and how fast you need your storage to be.
But they have local disks on them.
Let's just say they have, you know, 15 disks each.
And they're all the same size, all the disks across all the hosts.
They're built for this functionality, so they're all the same size.
They have the same number of disks, the same speed of disks.
And rather than just put VMs on host one, and that's where they live, it creates a virtual SAN.
So it's not central storage stored in one place.
It's on the host.
But what it does is it actually replicates the VMs between the other hosts.
So if host one is running a VM, and the VM is on that host, and the other four, five, or six hosts in my environment also are running vSAN,
that host one with VMA, that's running VMA, is also the copy of VMA, maybe on host three and on host six or something like that or host five.
And so that VM is in multiple places.
So then all of a sudden, if that host one catches fire again, all of a sudden host three can say, oh, I have resource availability for that machine.
And I have the machine, you know, copy the files on me.
I'm going to start VMA on host three.
And then host two can say, well, you know what, copy it over to me too.
Because we need to have, you can configure, you know, an N plus how many copies you want.
Maybe you have a N plus two kind of configuration.
So we have the one we're running, and we want two copies of it.
So when host one caught fire, I had the one running and one copy of it.
So host two says, give me another copy.
Copy to me also, so that way we can keep up our N plus two, you know, failover capability that we were hoping for.
So vSAN is a way of using local disks on your hosts as if it's shared storage out on the network.
And they replicate that across all each other.
It's very cool.
It's been around since I believe like vSphere 5.5 or something like that.
So it's been around since around 2000, I want to say around 2010, 2011, something like that.
So it's not super new, but it keeps getting better and better and better.
And we'll have a lesson on vSAN, and we'll talk about, you know, how we used to have to have cache disks.
And now with the most current version of vSphere 8, we don't have to if we have certain other requirements met, things like that.
So vSAN is a way of using local disks on our hosts as if it's a SAN, as if it's shared storage available on the network.
So here's a typical and traditional installation in our physical environment.
We have our hardware.
We have that physical server.
We are going to install an operating system on that box.
We're going to put an application on that operating system.
And that big, huge box is dedicated to just that one OS and maybe that one application or that one service that's running on that box, right?
So all the resources that, you know, this OS and this application need all come from that one box.
And you might find your utilization level be very, very low.
You might only find, you know, in a physical environment, if you had 100 servers, you'd be running like 10% utilization or something super low like that.
In a virtualized environment, you'll see here, as we discussed, you have this server, right, with all this hardware.
You have, you know, 30 cores, and you have 256 gigs of RAM, and you have however many hard drives you need, and you've got all these network cards.
And I installed ESXi.
I installed a Type I hypervisor on top of the hardware.
And then I create virtual machines on that host, and then I install an operating system on there, and I install my application or my service.
And on that same physical box, I create another virtual machine, install another operating system, and another application or another service.
And the great thing about it is these virtual machines are very secure containers.
So this VM doesn't see what's happening in that one, but this one doesn't see what's happening in the other.
They're secure containers so that what's happening on one CPU doesn't get affected by the other.
One can't see the other one's RAM.
You will sometimes see, you know, different security bulletins out there about a vulnerability where a hacker can do this weird thing,
but usually they have to have physical access to the box and all this stuff in order for that to become a problem.
It's very rare.
VMware has a feature they call transparent page sharing.
And quite a while ago, a professor at some university or somewhere figured that it was possible for a VM,
if you gave it really specific instructions in a certain way, to see what might have used to have been in RAM from another VM that's no longer there.
There was never any reports of that actually being done.
It was just proven that theoretically it might be possible kind of thing.
So VMware by default turns off transparent page sharing now.
But a lot of these vulnerabilities you hear about are either ones that are extremely difficult to take advantage of.
You would need physical access to the box.
You have to be in the data center.
Or it's something where it's, you know, very unlikely you'll get what you're looking for if you can even possibly execute this.
It's really, honestly, a very secure environment.
You would not have the government, DOD, large financial institutions like, you know, banks and lenders.
And, you know, Wall Street is using, you know, these types of things.
The New York Stock Exchange uses VMware.
Obviously it's been proven to be a very, very secure platform and allows us to, you know, take advantage of these resources.
So in a data center where maybe before I only was using 10% of my resources, now all of a sudden I can start using like 75% of the resources.
And I don't want to get to 100 because I want to have room for growth and room for spikes and things like that.
I want to have room to take hosts down so I can patch other hosts.
So maybe I get like up to around 75% utilization.
And if I start to go above that, I add another host or two or whatever I need to get back to that 75%.
And the hypervisor does this really fantastic job of policing who gets access to what resource and when.
So one VM doesn't get to monopolize the entire host or get to monopolize, you know, the network and things like that.
So that's what virtualization resource allocation looks like, where you have a hypervisor controlling when VMs get access to resources.
Now, one thing that's really cool you can do, too, is by default they'll all get equal access.
So they'll all get like a certain level of, you know, the same level of access to a resource.
But maybe I have an application that's just really critical to me.
And I need this application to be guaranteed to perform better.
So I can tell the hypervisor that I want this VM to have a higher level of priority to the CPU, for example.
Even though all these VMs have two virtual CPUs, so they should all be equal, this one needs a higher level of access.
And I can go in there and I can control things like shares and things, and we'll discuss that,
to make sure that this VM actually gets the resources it needs when it needs it and it performs at a higher level than the other ones if there's contention.
If there's no contention, they're all getting what they want, everything's fine.
But if they start to get constrained and now there's contention on the resource, I can control which ones have a higher priority or which ones have a lower priority to that resource.
So, in conclusion, we discussed virtualization basics and we discussed some terminology and components in virtualization.