1. Demo – Configuring VM Reservations and Limits in vSphere 7
As you can see, I’m currently logged into the Vsphere client. I’m going to go to Hosts and Clusters, and we’re going to work on this virtual machine called Demo VM, and I’m going to power it on. And one of the reasons I want to power it on is to kind of differentiate between what settings are available when a VM is powered on versus when it’s powered off. So I’m going to right-click this virtual machine and go to Edit Settings. And the first thing I want to point out is that I do not have the ability to modify the number of CPUs or the amount of memory while this virtual machine is powered on. Now, as you keep watching this course, there are ways to actually modify the CPU count in memory of a virtual machine that is powered on. But we’re not quite there yet. We’ll learn about that later on. So at the moment, I can’t modify the number of CPUs or the amount of memory that’s allocated to this virtual machine. Now, what I really want to focus on in this lesson is this area of the configuration. So I’ve configured this virtual machine with two virtual CPUs, but I have not configured any reservations, limits, or shares. So let’s start with a reservation.
A reservation is essentially a guarantee of a specific quantity of physical resources. So I might have many virtual machines on the same host sharing the same physical CPUs. And I may run into situations where there’s resource contention. I can utilise a reservation to guarantee a virtual machine a certain amount of physical CPU capacity on the host that it’s running on. So the benefit of a CPU reservation is that I’m basically guaranteeing this particular VM some of the physical resources of the host that it’s running on. And this is running on host 192-1681 9915.So I’m carving out some of the CPU from that physical host and guaranteeing it to this particular virtual machine. And the benefit is that, yes, this VM is always going to get a certain amount of CPU, but you want to kind of think of a reservation as a last resort. This isn’t something you want to do all the time. And the reason I say that is because, basically, you’re carving out those resources. That means that no other virtual machines can use the CPU reservation that I’ve made here. And this virtual machine is consuming all of those CPU resources that are reserved for it 100% of the time.
So even if the VM doesn’t need those resources, it’s taking them. And the analogy I always use for reservations, even though it’s kind of gross, is like a kid who licks a toy. So let’s say there are a bunch of kids in a room, and this kid wants the best toy. He grabs it, licks it, and starts playing with it. Now even if he stops playing with that toy, nobody else wants it because it’s been licked. And that’s kind of like a reservation. Once I grant this reservation to this virtual machine, it has those resources even if it’s not using them. No other VMs can use the resources reserved for this VM. Now, the other important thing to keep in mind about a reservation is that when I assign a reservation to a virtual machine, it cannot boot unless that reservation can be satisfied. So let’s cancel this and go to the host. This host has a finite amount of CPU capacity and memory, and once I create a virtual machine with a reservation, it is taking some of that resource capacity from the ESXi host. Now, that might not be a big deal. if it’s just one virtual machine, but let’s say it’s 25 virtual machines running on this host, and I’ve given all of them a CPU reservation.
Well, there’s a chance that as I keep booting up those virtual machines, they are going to completely exhaust the CPU resources of this ESXi host. And eventually I’ll get to the point where I won’t be able to power on any more virtual machines with the reservations because all of the memory of the ESXi host will be exhausted. And so that’s just something to keep in mind: when I create a resource reservation for a virtual machine, I’m also involving something called admission control. So if I give this virtual machine a CPU reservation that the ESXi host cannot satisfy, this VM will not be able to boot. Let’s say that this VM does successfully boot up, but then I try to migrate it to a different ESXi host using V motion.Well, if that destination host can’t satisfy this reservation, then I won’t be able to migrate that VM. That’s what we call admission control. And that’s an important side effect to understand when we’re configuring these reservations. So the bottom line is that reservations are really quite restrictive. They’re not the most flexible way to allocate resources to a virtual machine. And for that reason, I try to avoid reservations whenever I can. I only configure reservations on a VM when I have no other choice, and I tend to treat limits the same way. So limits are essentially just a hard cap on the resources that can be consumed.
So, for example, here I could create a CPU limit of 500, which would guarantee that this VM never consumes more than 500 CPU resources. And the limit is a hard rule that can never be violated. So ideally, I don’t want to configure these reservations and limits unless I have to. And there are similar reservations and limits when we look at memory. So I can reserve a certain amount of memory. I can create a memory limit as well. So the last thing that I want to take a look at before we move on here is that I’m going to shut this virtual machine down. And now that the VM is shut down, let’s right-click it one more time. Let’s go to edit settings. And now you’ve noticed, yes. Now I can modify the number of CPUs. Now I can modify the amount of memory that has been allocated to this VM.
2. Demo – Configuring Shares on a vSphere 7 VM
So I’m still in the VSphere client. And here’s the virtual machine that I was looking at in the last video. I’m going to right-click my demoVM and go to Edit Settings. And under CPU, I have the ability to configure reservations, limits, and shares. And we talked about reservations and limits in the last video, and we talked about how inflexible those resource settings are; shares are the exact opposite. Shares are built to be flexible. Shares are built to only be utilised during times of contention.
So shares define relative priority. And what that basically means is that if I have multiple virtual machines running on the same ESXi host, the share values are going to determine their priority for access to resources. And this share structure is only enforced during times of contention. So remember, with reservations, they’re enforced all of the time. The moment I boot up that VM, it’s consuming those resources. Shares don’t work that way. The share structure is only enforced if the ESXi host is running low on a particular resource and there’s actually contention between virtual machines. So for example, let’s assume that this virtual machine is configured with two virtual CPUs, and I configure a high value for CPU shares on this virtual machine. And now let’s assume that the ESXi host is running really low on CPU. And I’ve got some other VMs with a normal number of shares.
You can see the share value changing here. And the VM with the high number of CPU shares is going to get access to twice as many CPU resources as the VM with the normal number of shares. Now, there’s an important thing to understand here. This VM with a high number of shares is entitled to twice as much CPU as the VM with a normal number of shares. And that word “entitled” is an important one to focus on. As an example, suppose we have four people and we walk into a room where there are eight slices of pizza. Assuming that everything is equal, all four of us are each entitled to two pieces of pizza. We’re going to split it equally. Now, just because we’re all entitled to two pieces of pizza doesn’t mean that we’re all going to actually eat two pieces of pizza. Some of us may eat one piece and be completely satisfied at that point, and we may not want a second piece. But we all have an equal number of shares, right?
We’re all entitled to two pieces of pizza. Now let’s assume I’m really hungry that day. And I don’t want two pieces; I want three. Well, as long as somebody else doesn’t want their second piece, as long as there’s one piece left over, there’s no contention there. There’s no argument, there’s no fight, and there’s no contention for resources. And so I can have my three slices and they can have their one slice, and there’s no contention, so the share structure is completely irrelevant in that scenario. It doesn’t matter that they’re entitled to two pieces and I’m only entitled to two pieces. They’ve chosen to give me that other slice. So the share structure doesn’t matter. There’s no resource contention. Assume that all four people enter the room, and that all four people want three slices. Well, that’s when the share structure matters. You’re only entitled to two pieces. And so you can’t take that third piece because everybody is entitled to two. Everyone gets an equal share. So that share structure starts getting enforced when there’s actually contention for resources. And that’s exactly like the share structure here for this virtual machine. As a result, this virtual machine is entitled to a certain amount of CPU resources under normal circumstances. And the actual amount of CPU or the actual amount of memory depends on what else is going on within this host.
If there are no other VMs running, there’s no problem here. However, if there are many VMs running, the amount of CPU and memory will be determined by the number of shares in each VM and the total number of shares in all of them. The other VMs have, and whatever percentage of shares this VM has relative to all the other VMs, that’s going to determine the percentage of resources that this VM is entitled to. So I can kind of view the shares as a safety net. For example, this VM is configured with two CPUs. That means that as long as there’s no resource contention, this VM can consume 100% of two CPUs. But when contention occurs, which virtual machines should be prioritised during that time of contention? That will be determined by my share structure. So it’s basically a safety net where we’re basically saying that, under normal circumstances, you’re welcome to use two CPUs, but if contention occurs, this is how your entitlement is going to be determined. This is your relative priority compared to the other VMs. So we may have certain VMs that we really want to prioritise during those times of contention. We can do that with shares without limiting them during normal periods, without the strict enforcement of things like reservations and limits.
So yeah, it’s basically like a safety net. We hope that the share structure is never enforced, but if I run into a spot where the host is low on resources, I want to make sure that the right VMs get prioritized. So that’s why the shares are there. So that’s a look at CPU shares for a virtual machine, and memory is almost the same type of deal. Here we can set a low, normal, high, or custom number of shares for memory. And the share numbers here are based on the amount of memory that we’ve configured. So this VM has four gigabytes of memory. If I give it low shares, it gets 20,480 shares. Normal doubles that, and high doubles that. So the number of shares for low, normal, and high Those depend on the amount of memory that I’ve allocated to this VM. If I change that memory to eight gigs, you’ll notice now that my number of shares for normal doubles brings it back down to four. It’s cut in half. Now, the other option here is to actually input a custom value. So let’s say that I want to take this vehicle, and I want to say that this VM is really important. I’m going to give it, like, some custom value for shares, and I’m going to give it, like, a really high value for shares. You can do that. You can set up these custom values.
However, I typically don’t recommend that because it’s really easy to kind of go, “Hey, let’s just make it low, normal, or high.” If you start creating custom values here, you may really skew things by giving a VM way too many or way too few shares. You’re giving that VM a really high level of entitlement or a really low level of entitlement. And you want to make sure you have a consistent share structure that is easy to manage across all of these VMs. So while you can set up custom share structures under normal circumstances, I really don’t recommend that. High, normal, or low—those are your best bets to keep this share structure manageable and easy to work with. So that’s the concept of shares, and that’s a concept that we’ll also look at closely when we get to resource pools. But I just want to reiterate that shares are only enforced during times of contention, and they’re a really flexible way to make sure that your most important VMs get priority access to resources during times of contention.
3. Demo – CPU Hot-Plug and Memory Hot-Add for VMs
So here we are back in the Vsphere client, and this is the VM that we’ve been experimenting with for the last couple of lessons, the demo VM. And a couple of lessons ago, we noticed that, hey, I can edit settings on this VM. I can change the number of CPUs and the amount of memory, no problem, as long as this virtual machine is powered off. But once I power it on, I don’t have the ability to change the number of CPUs or the amount of memory. So let’s quickly cancel this and turn the VM back on. And so now, if I go to edit settings, I can no longer modify the number of CPUs or the amount of memory. Now, how do I get around this? Maybe I’ve got an operating system that supports the ability to dynamically add CPUs even when the virtual machine is powered on.
So I need to enable the CPU hot plug feature. Notice I can’t enable that here. There’s a similar feature for memory. I can enable the memory hot plug. But again, I can’t seem to change that feature. And the reason I can’t change it is because this VM is currently powered on. So let’s go ahead and shut it down here. And now that the VM is shut down, I’m going to right-click it, go back to edit settings yet again, and select CPU. I can now enable CPU hotadd, navigate to memory, and enable memory hot plug. And this is going to give me the ability to change the number of CPUs and the amount of memory on the fly, even when this virtual machine is powered on. So I’m going to go ahead and click on OK here, and then I’m going to power my demo VM backup.
So let’s power it on, and I’m going to launch my web console, and we’re going to get logged into this virtual machine. And once we’re logged in, we’re going to add some memory and CPU resources to it while it’s powered on. So now you can see I’ve logged into this virtual machine, and I’ve just started Task Manager so that we can observe the changes that occur here. So you can see right now that I’ve got one socket and two virtual processors for this virtual machine, and I’ve got four gigabytes of memory for this VM. I can see the performance details here within Task Manager. So now I’m going to go back to my Vs Fareclient, right-click this VM, go to Edit Settings, and use my CPU Hot Plugfeature to change the number of processors to four and the amount of memory to eight. And I’m just going to go ahead and click OK here. Now that I have successfully modified the number of CPUs and the amount of memory for a powered virtual machine, it’s important that my guest operating system actually supports this. So let’s go ahead and relaunch our web console here, and let’s take a look at the results.
So now I can see that the amount of memory configured is actually seven gigs of memory. And I can see that the number of processors has remained constant. But if I reboot this virtual machine, maybe it will recognise those additional processors. And so I rebooted my VM, and now you can see that it’s actually reflecting the changes in the number of CPUs. Now I’m not going to bother troubleshooting this issue right now. Most likely, this is an operating system-related issue most likely.But it goes to illustrate the point that I want to make here. And the point is that even though Vsphere supports the ability to do CPU and memory hot plugs, if there’s anything incompatible with the underlying operating system, then those changes won’t be reflected in the operating system of the actual VM.
4. Resource Pools and vApps in vSphere 7
So here you a database’ve got database server server, andplicatiserver. I may need to control the boot order of these virtualmachines That’s the typical use case for a VAP: to create a container object, which is very similar to a resource pool, but it also has the additional function of being able to control power on and power off orders. So if I need to make sure that my database server always boots up first and then my app server and then my web server, I can use a VAP. The VAP also includes all the features of a resource pool. So I can configure shares, limits, and reservations on a VAP. And just like a resource pool, those resource allocations will be divided among the virtual machines inside that VAP. So, in review, a resource pool is a container object.
It can be used to group virtual machines together. And we can configure things like permissions and alarms on a resource pool that will apply to all of the virtual machines within that resource pool. We can configure shares, limits, and reservations to provide resource controls across all of the virtual machines in that resource pool, and actually, they provide controls across all of the child objects of that resource pool. So a resource pool can potentially contain virtual machines, vamp’s, or other resource pools. Again, we can configure permissions and alarms in that resource pool that will apply to all of the child objects in that resource pool. And the root resource pool is the ESXi host or maybe the DRS cluster that that resource pool is created within. Child resource pools can be created within a resource pool, and any of the objects in a resource pool compete for the resources of that resource pool. And then finally, a VAP is very similar to a resource pool in almost every way. The big difference is that with a VAP, we can control power in order, not just resource competition.
5. Scalable Shares in vSphere 7
And so, in order to understand the need for scalable shares, we need to go back a little bit and look at how resource pools work without scalable shares. So here’s a resource pool. We’re going to call this the root resource pool. So, for example, let’s say that we have a DRS cluster and all of the hosts in that cluster combined have 48 gigabytes of memory. That’s my root resource pool. That’s the actual physical resources that are available here. So within that root resource pool, within a DRSCluster, I’ve created a normal resource pool, which has 40 shares of memory, and a high resource pool, which has 80 shares of memory.
And so I’ve got these two resource pools, and based on the shares configured, they are each entitled to a certain amount of memory, right? And the Normal Resource Pool has half as much memory entitlement as the High Resource Pool, which is exactly what we want here in this situation, right? We want our normal VMs to have a certain priority, a relative priority, as opposed to our high priority VMs, which should have twice the memory. So that’s the objective. But now we start placing virtual machines inside of these resource pools, and we don’t really track which pool has how many virtual machines. In this scenario, I’ve got one VM in the normal resource pool. That VM has access to all 16 gigs of memory. So the VM in the normal pool gets 16 gigs of memory, potentially as part of its entitlement. Whereas the VMs in the high resource pool each have an equal number of shares, They’re dividing up 32 gigabytes of memory between them, meaning that the VMs in the High Pool have a maximum of eight gigabytes of memory entitlement each.
So in this scenario, even though the High Resource Pool has more shares, the VM in the Normal Resource Pool actually has access to more memory because there are fewer VMs running in that pool. And so this is a problem that we’ve had with VSphere for a while, where resource pools are a great way to define resource allocations across a large group of virtual machines. But if the number of VMs in your different pools gets skewed, it can lead to basically the opposite of the results that you were looking for. So that’s the problem that Scalable Shares was created to resolve. So let’s compare that to a resource pool where scalable shares have been enabled. So this is a resource pool that’s created within a DRS cluster, and that DRS cluster itself has scalable shares enabled on it. And within that DRS cluster, I have two resource pools: normal and high. And within those resource pools, I have virtual machines. Now, we’re going to make one assumption here. Let’s assume that each virtual machine is configured with 1000 memory shares. So the actual share configuration on the virtual machines themselves is for 1000 shares. So let’s take a look at how this breaks down. In my high resource pool, I have four virtual machines.
They have 1,000 shares each. So from that, I get a total of 40. So I have 40 shares for my four VMs. I multiply that by the relative priority of my resource pool. So for example, if a resource pool is configured with a large number of shares, we’re going to multiply that by four, giving us a total of 16,000 shares across the four virtual machines, or 4000 shares each. So each of those VMs is getting 4000 shares from the root resource pool. How about my normal pool? Well, I’ve got one VM with 10 shares. We’re going to multiply that by two. The value is two for normal priority resource pools, giving us a total of 2000 shares. So the end result is that even though the high resource pool has more VMs, they end up with 40 shares each from the root resource pool. This VM in my normal resource pool ends up with 2000 shares from the root resource pool. So the actual entitlement of this VM is only 20 shares, versus these, which are 40 shares. And so now the structure of the resource pool basically takes into account the number of virtual machines that are running within it. And even though my high resource pool has more VMs that are running inside of it, those VMs are each still going to get twice the memory shares of that VM in that normal pool. And it doesn’t matter how many VMs are in each pool; this relative prioritization stays intact.
So it’s a huge improvement over resource pools prior to VSphere 7. and I just want to make a note. The content of this lecture is based on an article on yellowbricks.com. I definitely recommend visiting this website. It’s yellow-dash Bricks.com. Duncan Epping is one of the mainauthors on this site and you’ll oftennotice information from Frank Deniman as well. They produce a tonne of great information on clustering and resource management across vSphere. And so I definitely recommend checking out this website if you haven’t already seen it. But yeah, they kind of go through, “Hey, how did they come up with this feature?” These are the guys who created it, and what is the end result of it? So it kind of breaks down a similar scenario that I gave you as to how the shares are actually calculated within these resource pools. And then there’s a nice little video demo here at the end of this website showing you scalable shares in action. And frankly, I didn’t record a demo on this because it’s hard to reproduce the sort of resource contention that they’re showing here. So I definitely recommend coming in here and watching this video to get a really great look at the actual end result of scalable shares being implemented in a Vs. Verse Seven environment.
6. Demo – Create Resource Pools in vSphere 7
And so here you can see I’m logged into the Vsphere client, and I’m going to go to Hosts and Clusters. And under hosts and clusters, I’ve got some virtual machines that are already created here. And the other thing I want to make note of is that these virtual machines are running on standalone ESXi hosts. So these hosts are not in a DRS cluster. I can create a resource pool within a standalone host, but I can also create resource pools within a cluster. So I just want to make that distinction. So in this demo, I’m going to create a resource pool on an individual host. However, if I were to have a DRS cluster, I could create a resource pool, and the resource pool would be present, spanning the resources of the entire DRS cluster. So I’m going to right-click this first host here, and I’m going to create a new resource pool. And the resource pool is essentially a container object.
So this resource pool is going to contain multiple virtual machines, or potentially even multiple child resource pools. So I’m going to call this first resource pool “high.” And what I’m going to do here is modify the CPU shares. I’m going to make the CPU shares on this particular resource pool high, and I’ll also grant a high number of memory shares as well. And this is a great way to use resource pools. So what I’m essentially saying is that within this resource pool, I could have multiple virtual machines. And the virtual machines that are within this resource pool can utilise the shares that are granted to this resource pool. So let’s just start with a really basic example here. This is my high resource pool, with a high number of CPU shares and a high number of memory shares. I’m going to click “OK” here. And here we can see the new resource pool. I’m also going to create two more resource pools. I’m going to call my second resource pool “Normal,” and I have a normal number of CPU and memory shares in this pool. And then I’m going to create a third resource pool. This one I’m just going to call Low, and I’m going to have a low number of CPU and memory shares in this third resource pool.
And so now I’ve got a couple of VMs here. If I have a virtual machine that I consider to be of high priority, I can just grab it and drag it into my High Resource Pool. If I have a virtual machine that I consider to be of low priority, I can drag it and bring that VM into my Low Resource Pool. So I can very easily just place virtual machines in different resource pools based on their relative importance. So I’m going to click on my high resource pool here. And here you can see the nice little summary screen for this resource pool. We can go to Monitor and see the CPU, memory, and storage reservation details. So in this scenario, have I created any reservations on my resource pool for CPU? I have not. I have also not created any memory reservations either.So if I want to make those sorts of reservations, I can always right-click my resource pool and choose Edit resource settings, and I can make modifications there. So let’s say, for example, that on the high resource pool, I grant a reservation of 1000 MHz for CPU. That is, I guarantee 1000 CPU to this resource pool on this ESXi host 100% of the time. You can also view the maximum reservation here.
So I’m taking a significant chunk of resources that are available on this ESXi host and permanently allocating them to this particular resource pool. And maybe I’ll guarantee this resource pool some memory as well. Maybe I’ll guarantee it with 4000 megabytes of memory. And this is critical if I’m going to have virtual machines with reservations. So if I’m going to take virtual machines with reservations and place them inside of this resource pool, that will only work if the resource pool has reservations that are sufficient to satisfy the reservations of the VMs. So, for example, if I have three virtual machines, each with a 500 MHz CPU reservation, that is going to exceed the available reservation of this resource pool. So will I be able to boot up those VMs up?Will I be able to put those VMs in this resource pool, power them on, and have them successfully boot? and the answer right now is yes. We’re going to learn more about that in the next video when we breakdown how expandable reservations work.
So for the moment, I’m actually going to uncheck expandable reservations. And given this configuration, if I have those three VMs, each with a 500 MHz reservation, I will not be able to power all three of those on. So I need to configure my resource pool with significant enough reservations to accommodate all of the reservations of every VM that’s going to be contained in this resource pool. So now I’ve configured this resource pool with a couple of reservations. I’m just going to go ahead and hit OK here. And now if we go back to this monitor tab on the resource pool, I can see my memory reservation, the available reservation, and the used reservation, and if I go to the CPU, I can see something very similar. So the fact that I have now configured these reservations means that it’s going to immediately start consuming resources on this ESXi host. And if I go to the ESXi host and go to monitor and I go to resource allocation, you can see here, “Hey, here’s the total host capacity for CPU, here’s the total reservation capacity, and here’s the amount of reservation that’s been used for CPU.” So I’m consuming some of the reservable CPU resources. same thing with memory. I’m using up some of those reservations now. And so the moment I start configuring reservations on these resource pools, I am tying up the resources of whatever they are running on, whether it’s a host or a cluster, and I’m chewing up those resources.
Okay, so now let’s talk about another use case for these resource pools. I’m going to go to my low resource pool, and I’m going to right-click that one and edit resource settings. Now, this is a really low-priority resource pool, so I’m not going to grant any reservations. But what I might want to do is set up some limits. So let’s say that this resource pool is for my development virtual machines, and they’re constantly running tests and trying things out.
And I essentially want to say, “You know what, for this group, for these development VMs, I don’t want them consuming more CPU than I’d like them to have access to.” So maybe what I do is set a CPU limit in megahertz. Maybe what I do is set a memory limit in megabytes. And what I’m doing now is essentially limiting the amount of resources that the VMs in this resource pool can consume. So that’s a great use case for this: maybe for that kind of development or testing group of virtual machines, I want to place a hard limit on the amount of resources that they can consume. Now, do I really need these limits and reservations? Probably not. I’ve already configured a share structure on these resource pools that should ensure that the virtual machines are getting the appropriate resources. So the share structure should really take care of all of this for me. I don’t necessarily need limits. I don’t necessarily need reservations because the high pool has more shares than all of the other pools do.
So do I really need to guarantee resources here? Probably not. Probably not. And ideally, what I’d like to do is avoid reservations and limits unless I absolutely need to configure them. Now with that being said, prior to VSphere 7, I had to really think about how many virtual machines I was going to put in each of these pools. I wanted a relatively even distribution of work. For example, if I have 20 VMs in the high pool and only two VMs in the low pool, the VMs in the low pool will receive more resources than the VMs in the high pool. And we just learned about this concept of scalable shares in the last lesson, where it’s going to essentially normalise and overcome that problem for us. However, in this situation, I’ve enabled these resourcepools under individual ESXi hosts, and so scalableshares is not going to help me here. These have to conform to the old standards. I need to make sure that I’m evenly distributing virtual machines across these resource pools and that I’m not skewing my share structure, so scalable shares are only enabled at the cluster level. So let me just show you very quickly.
If I go create a new cluster and I enable DRS on my cluster, then within the DRS cluster, I can go to the settings of my dress cluster, and I’m just going to skip my quick start here. So I’ll just click on these for DRS for my cluster, then go to edit and under additional options. Scalable Shares can be enabled on resource pools in this cluster by me. So just keep that in mind if you’re creating resource pools on individual ESXi hosts or on a cluster that does not have DRS enabled, or even if it’s on a cluster that does have DRS enabled. Scalable shares are not enabled by default. So if you’re counting on Scalable Shares to handle some kind of imbalance between these resource pools, just make sure that you’re creating your resource pools within a DRS cluster and that you’ve enabled the Scalable Shares feature.
7. Demo: Expandable Reservations in vSphere 7
So here I am in my virtual world. HTML-5 client, and I’m going to click on hosts and clusters. And you can see I’ve got three resource pools created, called high, normal, and low. So let’s say, for example, that in this normal resource pool, I have my resource settings configured as shown. I have disabled expandable reservations, and I haven’t configured any sort of significant reservations for either the CPU or memory. So I have to configure some memory reservation here just because I’ve got a virtual machine running in this pool, and I have to reserve a certain amount of memory for overhead for that virtual machine. So I’ve created a really low memory reservation of 60 megabytes and disabled expandable reservations. I’m going to hit OK here, and I’m actually going to power off this virtual machine. Now you don’t have to turn off aVM to configure shares, limits, and reservations. But I want to actually illustrate something here. So I’m going to have this VM powered off, I’m going to edit the memory settings, and I’m going to give this virtual machine a one-gig memory reservation.
Now bear in mind that one gigabyte of memory exceeds the reservation available in the parent pool for this virtual machine. So I hit OK here, and I have now successfully configured that reservation on this VM. I’m going to try to power the VM off and see what happens and what it says. Operation failed. The available memory resources in the parent resource pool are insufficient for the operation. I can’t power on a VM with a one-gig memory reservation because the parent pool cannot satisfy that reservation. So the normal pool doesn’t have enough memory reservations to satisfy that one gigabyte reservation. If I make a two-gig memory reservation on this pool, I can now power on this VM without issue. So I’m not going to see an error powering on the VM. Now it’s going to work just fine. Okay? So let’s power this VM off one more time and try another little test. So this VM is still configured with a one-gig memory reservation. I’m going to go back to the parent pool, edit the resource settings, and I’m going to bring this reservation back down to 60 megabytes. And we saw this a few minutes ago.
So with a 60-megabyte reservation, my rickfrom-template VM was unable to power on. But this time I’m going to enable expandable reservations and hit OK. Let’s see what happens if Itry and this VM are both powered on. It worked just fine. The VM with a one-gigabyte reservation was able to power on even though it was in a resource pool that only had a 60-megabyte memory reservation. And that worked because I marked the reservation type as expandable. So, if a VM with a one-gig reservation tries to power on and this pool only has a 60-megabyte memory reservation, it will fail. The expandable reservation allows this resource pool to reach out to its parent. Its parent could be another resource pool, but in this case, its parent is this ESXi host. So now the reservation for my virtual machine is actually being satisfied by the ESXi host. That’s what an expandable reservation means. It basically means, “Hey, if you don’t have the resources, you can then try to borrow them from the parent resource pool.” You can try to borrow them from an ESXi host or a cluster, or maybe this resource pool is nested within another resource pool.
Regardless, you can try to borrow them from your parents. And if I go ahead and power off this VM one more time here, we can take a look at the monitor tab for the ESXi host. Now it says to use reservations as one gig. If I refresh that, it’s going to go back down to 60 megabytes. That’s the reservation that I configured for my normal pool. So expandable reservations can be a little tricky because, basically, what I’m doing is removing the controls here, right? I am saying, “Hey, if VMs boot up in this resource pool, even if the resource pool cannot satisfy their reservation, they can then reach out and try to get that reservation satisfied by whatever the parent resource pool is.” It might be this ESXi host; it might be another resource pool. It might be a DRS cluster. So we need to exercise caution when enabling expandable reservations. And just understand that when you configure these, you’re basically eliminating the controls and allowing those reservations to be satisfied even if the resource pool itself cannot satisfy them.
8. Demo: Configure vApps for Multi-Tier Applications in vSphere 7
In this video, I’ll demonstrate how to create a V application. So here I am in the Vsphere client, and I’m going to go to hosts and clusters. And what I’m going to do is create a couple of virtual machines specifically for the purposes of this demo. So I’m going to create three VMs. And let’s assume that we are in a situation where we have a web server. And so the web server is providing some kind of web resource to the outside world. And so people are accessing this web server.
They’re serving up a web page from it. On the back end, we’re going to have an application server as well. And this is a pretty common design. So if we have an application server on the backend of this, the web server is going to rely on that application server in order to function. So it’s important that the application server boots up before the web server does. So let’s really roll out an app server virtual machine. And again, these are just fictitious VMs. They’re not actually going to do the things that I’m saying they’re doing. I’m just naming them something descriptive for the purposes of illustrating a concept. So here’s my application server VM. The web server relies on the application server VM. So the web server can’t function if the application server is not up.And then let’s add one more virtual machine. Let’s call this our database virtual machine. And the application server relies on the database VM.
So this is a pretty typical multitier application. We have a web server, an application server, and then, on the back end, a database server. And it’s important that these three virtual machines boot up in the proper order, because if they don’t, then the application components aren’t going to function properly. Okay, so now I’ve got my three VMs. I now have my website, app, and database. I’m going to right-click on this ESXi host, and I’m going to create a new V app. And the new VAP is actually very similar to creating a resource pool. So as we go through the next few screens, we’ll talk about some of those similarities. I’m going to create a new VAP, but if I did have an existing VAP, I could clone it. I’m not going to do that. I’m going to create a new VAP. I’m just going to call it Rick Demo the app. I’m going to put it in my training software-defined data center. And like I said, this is very similar to a resource pool. So with the resource pool, you can allocate CPU shares, reservations, and limits; and memory shares, reservations, and limits. And these resource allocations that I configure here will apply to all of the virtual machines inside of this VAP.
So, for example, if I grant this VAP 4000 CPU shares, those 4000 shares are going to be divided up among all of the VMs inside of this VMP. So I’m going to leave these configurations at their defaults here.What I really want to talk about is not the resource configuration capabilities. I want to talk about some of the other capabilities of VAP. So I’m going to take my app server and I’m going to drag it into my VAP. I’m going to take my DB server and drag it into my V app and my web server. And now I’ve got a container object, myV, that contains three virtual machines. So let’s see some of the other cool things that we can do within this V application. So I’m going to right-click on my V app and go to edit settings. And you already saw this part: the source configuration that we could establish. How about the start order? What I can do is group my virtual machines into separate groups and control the start order of those separate groups. So, for example, my database VM will be assigned to Group 1. I’m going to make my app server part of Group 2.
And my web server is part of Group 3. That’s my boot order. The DB needs to start first, and the app server needs to start second. The web server must be started. And so when I start up my Vapp, group one is going to start first. Now, once group one finishes starting, then group two will start. But I don’t want it to happen instantly. I don’t want to power on my DB VM and then instantly power on my app server because the DB will not be completely booted and I want it to be completely booted before the app server begins. So what I’m going to do is, on group one here, I am going to configure a delay. Maybe I’ll make this five minutes or 300 seconds. I’m going to leave it relatively short here, though, because I want it to move quickly in my lab environment. So I’m just going to make it 15 seconds. Although in a real production environment, you’d probably make it a little bit longer than that. However, group two will not begin until group one has begun, and there will be a 15-second delay. Then group two will start up.
And I’m going to say that group two, my app servers, should power on. And then group three should not begin until VMware tools are ready for group two. And when we actually watch this in action, we’re never going to get to group three because group two doesn’t have VMware tools installed. But yeah, so those delays are there to make sure that, hey, when I power on this V app and I’m at the monitor screen here so that we can watch all of the events occurring here, I’m going to power on this VAP. It should start up the DB virtual machine right away. So that should happen almost instantly. It does. The DB virtual machine has immediately begun powering on. Let’s watch our recent tasks here at the bottom of the screen. So the DB VM is now powered on. It should be about 15 seconds, and that was just about 15 seconds before the App Store started going. So now the app server is powered on after a 15-second delay. And you can see down here the start times of 547 seconds for the DB server and 547 and 15 seconds for the app server. And so now the app server—a virtual machine—is going to launch.
And if we remember the configuration of our VAPhere, if we look at the settings, group three is not going to start until group two has VMware tools up and running. And our app server does not have VMware tools on it. So that’s never going to happen. So eventually this will time out, and it won’t successfully start the entire VAP. So, let’s take a closer look at our VAP right now. I’m just going to go to edit settings again and let’s look at the power off action so I can also right-click my VOP and power it off. And what it’s going to do is simultaneously power off all three of these groups. So I may want to change that. Maybe I want to make it a guest shutdown instead, so that the virtual machines will gracefully shut down. Maybe I want to incorporate some delays here, like the web server. This is now going to go in reverse order. So maybe I’ll give the webserver 240 seconds to shut down. Maybe I’ll give the app server 120 seconds, and then finally the third one will be the database server. I can change that, but please be aware that the power off action is always a hard power off. So it’s not going to gracefully shutdown the operating system by default. So that’s how you make a vamp and use it to control the power on and off of a group of virtual machines.
