Welcome back to vSphere 8 in the real world. And now we're going to discuss an introduction
to resource allocation. Resources are basically going to be things on your ESXi host or in your
vSphere virtual environment, your CPU, your memory, your disk, your network, things like that
are all going to be resources that you're going to want to allocate and you're going to want to
control the allocation of. So resources are going to be assigned to the virtual machines.
So basically, it's super important that when you're assigning resources to VMs, you don't
think about your VMs like you would a physical machine. When we go out to buy a physical box,
we know that we're making an investment. And often if we want to upgrade a resource on a
physical machine, that means taking something out that we paid for and replace it with something
else that's newer and greater and better. And maybe we paid X number of dollars for this
processor. We're going to upgrade the processors. And maybe we paid $500 for this processor. And
the new one's $1,000. We're not just going to have to pay the additional $500 to get the newer,
greater processor, right? We're going to take out the $500 one, spend $1,000, put the $1,000 one in,
and now we spent $1,500 on processors and we have a $1,000 processor.
Virtual machines obviously are not that way. We don't need to invest everything in the VM when we
create that VM new. We want to allocate the minimal resources needed to run that VM effectively under
its highest load, all right, but not say, well, I think in three years, we're going to really need
this much. I can run it today with four virtual CPUs, but I think in three years, it's going to
need eight, so I'm going to give it eight. If today it needs four, then you want to allocate
four. If today it needs four gigs of RAM, but you think it might need 12 in three years, you don't
allocate the 12, you allocate the four because you want to allocate the resources as sparingly
as possible because in three years, that RAM is going to be a lot less expensive, right?
So, go ahead and add the additional RAM in a year, two years, three years when you need it,
and it's less expensive than it is this year. When you're buying a physical machine, that's
not necessarily your thought process because you don't want to throw away the resource that you
just bought and have to buy part of it again and then plus the upgrade, right? So, when you're
building VMs, you want to make them as small as possible using as few resources as possible
while giving it the resources it needs to perform its job. We don't want to get ridiculous and say
we're going to give it, you know, 512 megs of RAM in one process and we're going to try and run a
Windows SQL server. Obviously, that's not going to work, but you don't want to oversize it like
you might a physical box. We can always add RAM later. We can always add some, you know, virtual
CPU cores to it later when they're needed. Maybe for the first six months, we're just going to be,
you know, building this application out and adding some, you know, resources to it, adding more data
to the database. And as it grows in six months, then in a year, all of a sudden, we need more
disk space. We need more CPU. We need more RAM, whatever the case may be. We can add those later.
And again, those resources are going to be cheaper later than they are now. So, if we need to buy
more later, that RAM is probably less expensive than it was a year or two years ago, right?
So, what type of resources are we going to manage? Basically, everything that's related to a virtual
machine, the networking, storage, power, memory, CPU can all be managed. Network utilization,
we have storage, I'm sorry, network IO control. We have traffic shaping where we can, you know,
throttle how much bandwidth VMs use. We can prioritize certain VMs that have higher priority,
lower priority through network IO control, things like that. Storage, we have storage
IO control. We can also say that certain VMs have to live on less expensive storage to allow
the more expensive storage that we have less of to be available to the VMs that, you know,
need it more, that are more important to us where performance is a higher priority,
you know, things like that. Power, we can actually configure power management. So, we can say
during slow times when the VMs are currently being used, maybe we only run our shop 8 to 5
Monday through Friday. We're not a 24-7 shop. So, we don't want to run all, you know, 15 hosts
24-7, 365. So, maybe we say at night, we want to move all the VMs down to seven of our 15 hosts,
and we're going to power down, suspend, hibernate the other ones that we're not using. Then,
as we need them, we can kick them back up again. We can use, you know, things like ILOs and stuff
for vCenter to be able to go in and bring those hosts back out and start moving VMs back as we
need it. Or maybe we, you know, don't need them on the weekends, and so we do the same kind of
thing over a weekend or something like that. We can schedule a system and say, when you see
resource utilization is very low, use fewer hosts and, you know, power down the hosts that we don't
need, and we'll be able to bring them back online. So, we have power management. Memory. So,
we can actually over-allocate memory on our hosts, and we can use some things like page files,
paging. Those things are not going to be very efficient. They're not going to be very fast.
They're going to be slower. They're available if we need them. Another option, though, and this is
something that used to be turned on by default, and now it's turned off by default because it
was considered to be or is considered to be a security vulnerability, and that's transparent
parent page sharing. So, let's say in our environment we have, you know, 30 VMs running
on this one host, and we do a great job of standardizing. So, all of our VMs are running
the same version of Windows. They're all running, you know, 2019, and they all are patched to the
same patch level. That means a big chunk of that operating system on all those VMs are identical,
and so the pages and RAM are identical. So, I don't have to write all those pages and memory
for all those VMs, you know, say 19 VMs, 19 times. I can write it once, and when another VM starts,
oh, same page and RAM, I'm going to map you to that same page, and another one, I'm going to
map you to that same page. So, now I've only used, for 19 VMs, I've only used that page and RAM
once, not 19 times. Now, it was considered to be a security vulnerability because it was proven
through a, you know, a university that theoretically that RAM can be compromised by
another VM. It could be read, but it was actually something that never was found. It actually
happened out in the wild, and in order for it to happen, they had to have physical access to that
server, and my thought is if they have physical access to your servers, they already own you.
They own your servers. Transparent page sharing is the very, very least of your concern,
and the benefit definitely outweighs the risk. That's my perspective. Your company might have
a policy that says we do use it, we don't use it, maybe they don't have a policy on it,
it's up to you to make that policy. I'm very comfortable using transparent page sharing. So,
that is another tool that can be used to help, you know, control how much memory is being used
and allow me to over-allocate my memory, right, to allocate more RAM that I physically have in my
house. And then CPU. For things like the CPU for memory, those are the first ones that were
available. There's now other resources as well, like storage. We have what are called shares,
and we have reservations, and we have limits. So, reservations mean if I have a VM and I
configure the VM for a gig of RAM, and I create a reservation for that VM for half of a gig of RAM,
that means that VM is guaranteed, it's reserved a half a gig of RAM. Now, it can maybe have the
whole gig, right? If I have that whole gig available, then the VM gets the whole gig.
But if I've over-allocated my memory, that VM's going to be guaranteed that, that half a gig. And
as I start up another one, another one, another one, another one, and they start having their
reservations met, what might end up happening is I've over-allocated my RAM so much with so many
VMs with so much RAM that when I go to start up my 30th, my 50th one, the VMs all have half their
gig reserved, if that was my configuration. The other half has to be paged or something like that
because I don't have room in RAM to meet that need. So, they get their reservation, but they're
guaranteed if I configured that. The rest has to be paged out or something like that. Then I go
start another VM and it has a half a gig reservation. If I don't have a half a gig to give it, I can't
start it. When I go to start it, I'll get a message telling me that my reservation can't be met. And
because my reservation cannot be met, I cannot start that VM. So, reservations are guaranteed
resources. Limits are the opposite. Maybe I configured my VM for a gig of RAM, but I put a
limit on the VM of half a gig, which means it can use up to a half a gig of physical RAM. It's not
guaranteed it, but if it's available, it can use it. And even if more than a half a gig is available,
I want to go and use, you know, a half a gig plus one meg of RAM. And it's available and it's free,
but if I have a limit on there of half a gig, it can't use it. The VM thinks it's there. The VM
can say write that additional one meg, but the host will say that has to be paged. We're going
to page that out. I'm not going to let you write it to actual memory because you have a limit on
how much memory you can use. We can do the same thing for both of those things for CPU. We can
have a reservation for CPU for so many megahertz and we can have a limit. And so, you can't use
more than so many megahertz. And again, the VM might think it has more available, but it hits
that limit and there's an opening that starts getting this throttle down. And what will start
happening is you'll see it's latency going up and up and up on that VM. It'll start getting really
slow. But reservation means I'm guaranteed a certain amount of CPU. I'm guaranteed, you know,
1,000 megahertz. Even though this core is 3,000 and the VM can see that 3,000, I'm guaranteed
that 1,000. So, if other VMs are trying to use it, that right there is mine. And even if I'm not
using it, I'm not using that CPU time. I'm not using that 1,000 megahertz on that CPU. It's
reserved. It's mine. Okay? The way to get around things like shares and limits where even if I'm
not using it, it's mine or if it's available, I still can't use it are what they call shares.
Shares will allow for me to configure a VM and I power it on and it says, oh, yep,
all the CPU is there. This much RAM is there. Go ahead and use it. And if it's available and
there's no contention for it, and that's the magic word, there's contention. If there's no contention,
I can use all that I'm configured for. If I'm not using it, someone else can use it because
it's not reserved for me. And if I want to use it, it's available. But if there's contention,
meaning that, again, I've over allocated, for example, my CPU. I have more VMs running,
consuming processor than I have processors. There's more megahertz being eaten by these VMs
than I have megahertz on this processor. Now we have contention. We have VMs fighting for
access to that resource. How do I decide? How does the kernel decide who gets access to what?
I can allocate shares. And when contention comes into play, then shares come into play.
Unlike reservations, that's mine no matter what, if I'm using it or not, or limits, I can't use it
even if it's there. With shares, it only comes into effect when there's contention, when there's
fighting for a resource, and they'll say, okay, this VM has 500 shares, and this VM has 500 shares,
and this VM has 500 shares. All these VMs have 500 shares. So they get equal access to the
resource. They want more than there's available, but they're going to get an equal amount of it.
Then all of a sudden, I go to one of the VMs. I say, okay, I'm going to bump up your
500 shares to 1,000 shares. So now you've got 1,000 shares, and this VM has 500,
and this VM has 500. So in total, in the pool, there's 2,000 shares. This VM
has half of them. This one has a quarter. The third one has a quarter. That means that the
VM with 1,000 shares gets half the resource because it owns half the shares. The other two
own a quarter each, so they get a quarter of the resource. So your shares say what
amount of the resource you get access to when there's contention. But if there's no contention,
shares don't come into play, and you get all that you want, all the CPU you're configured for,
all the RAM you're configured for, if you want it. It's available to you. Until there's contention,
then shares kick in. So we can manage resources in our ESXi host, as you can kind of figure out
here, a lot of different ways. We have storage IO control, network IO control. We have shares. We
have limits. We have reservations. There's a lot of ways of controlling access to these resources.
So where do I assign these kinds of allocations resources, right?
So what can provide a resource? A host can. A host can provide CPU. A host can provide
memory and storage and network, and it can be power managed, right? We also can assign a resource
or get resources from a cluster or pool or resource pool. A cluster is basically a top-level
resource pool. When we want to go and create resource pools in vCenter, we have our cluster,
and then we're going to go into our cluster and we're going to start creating resource pools,
and we can choose to put VMs in resource pools. And resource pools, rather than going to the VM
and saying you have 1,000 shares and you have 500 and you have 500, I said the resource pool
has 1,000 shares. And this resource pool has 500, and this resource pool has 500.
So where are they getting that resource from? The pool, the resource pools get their resources from
the cluster, right? So the cluster is basically the top-level resource pool that then gets divided
up amongst the resource pools that are below it. So if a resource pool has 1,000 shares,
and then you have 500 and 500, all the VMs in that resource pool get half of the resources
in the cluster. And then the other ones get a quarter and a quarter. It doesn't matter how
many VMs are in that resource pool. The resource pool that 1,000 shares maybe has two VMs. Those
two VMs get half of the resources in that cluster. Then the other resource pool that has 500 maybe
has 10. Those 10 share the quarter that their shares give them access to when there's contention.
No contention, shares don't come into play. But when there's contention, then the two VMs that
are in the pool of 1,000 shares, they get half the resources. And the other ones get the share,
the quarter and a quarter. No matter how many VMs are in there, that's all they get that quarter.
Within the resource pool, so I have this resource pool with 500 shares and it has 10 VMs,
how is the resources amongst them shared? It depends on how many shares they have. If they
all have the same number of shares, they equally share their quarter of the resource. If one has
more shares, it gets, you know, based upon whatever ratio of the shares it has, that much of the
resource, just like we explained. So the VMs get shares within the resource pool. The resource
pool gets allocation to the resource of the cluster. So it's a pretty cool concept. It works
kind of well. It's easy though, as you might be able to see. I'm like, well, these VMs are really
important. I'm going to give their resource pool 1,000 shares, not thinking there's only two VMs
in there. They can't even use half of the resources in there. The other two resource pools only get a
quarter and a quarter because they only have 500 shares, but there's way more VMs in there.
So resource pools are great. I'm not trying to discourage anyone from using them, but make sure
you really think it out. It's not going to be something you're going to do on the fly on a whim
because what you'll find is if you don't think it out thoroughly, you're going to start choking
your VMs. You have some VMs performing horribly, other ones performing great because it wasn't
planned well. Resource pools are great to use. Shares, reservations are cool. Just make sure
that you think out the shares in relationship to the resource pools, in relationship to the number
of VMs, the size of the VMs, things like that. So what can provide the resource hosts? Clusters
and resource pools, and data stores provide storage, obviously. So what uses the resources
from the host, the cluster, the resource pools, or the data store? Virtual machines and virtual
applications do, obviously, as we kind of just explained. So these are going to be the consumers
of the resources that will be available that are provided by our clusters, our hosts, our resource
pools. So we can use all of these to help us plan the allocation of the resources to our virtual
machines, to our applications. So we can have some kind of predictability that when there is
contention, when this thing kind of gets bigger and we're really busy, which virtual machines are
going to be prioritized? Which ones are going to get more resource because they're a higher priority
virtual machine? Which ones get fewer resources because they're less of a priority? They're less
often used and the work they do isn't as important. But these other applications, they be the main line
of business. They are what drive sales. They are what drive production, things like that. We need
to prioritize those so we can allocate resources to them to make sure that happens. So it makes
our workloads more predictable during heavy utilization times. When things are fine, when
there's not a lot of heavy utilization, there's lots of resources, we don't have to worry about it.
We're using these to ensure a certain level of performance so we can deliver on our SLAs to our
end users during heavy usage times, during times of contention for the resources.
So the goal here is efficiency, right? We want to make sure that resources get used as
smartly as possible, right? Balance of the VMs that need the resource get the resource and the
VMs that aren't as important don't get as much. But if I have 10 VMs that are very important and
they all need to have a good level of performance, that the resources are being balanced among them.
I don't want one VM just to like get this, what they call a noisy neighbor, just consuming a lot
more resources than the other ones that are equally important for making sure our business
is successful. So I can use things like shares to ensure that balance, right? And ensuring the
VM can operate. What that means is maybe I have a bunch of big VMs and they're consuming a lot
of resources and I have one or two small VMs. I don't want them completely written off. I don't
want them out there choking and starving and not getting any resource because the big VMs are
sucking all of it up. So even small ones with maybe a small number of shares will get still a small
amount of resource, enough that they can operate efficiently enough for their level of importance
in our operations. All right. So we discussed resource allocation and resource management.
We discussed CPU, memory, disk, storage, and power.