Demo: Configuring shares on a vSphere 6.7 VM - vSphere Tutorial

- In this video we'll configure shares for CPU and memory on a virtual machine, and talk about how this share structure can impact the performance of virtual machines running on an ESXI host. So here I am with the vSphere client, in vSphere 6.7. I'm going to click on hosts and clusters, and I've got a virtual machine already created here, so I'm going to right click this virtual machine, and go to edit settings. And under edit settings, I've got CPU and memory settings here, so I'm going to start with CPU, and notice I've got the ability to configure reservations, limits and shares. So reservations and limits, those are pretty strict, those are pretty inflexible. Shares are the exact opposite of that. Shares define relative priority. So if I have multiple virtual machines running on this ESXI host, they can all have different share values. And those share values determine which VM gets relative priority during times of contention. So for example, let's say I've got this virtual machine configured with two CPUs, and high CPU share values. That means this VM has 4000 shares. If I have some other virtual machine running on that same ESXI host, with a normal number of shares, basically, the VM that's configured for high shares is entitled to twice as much CPU resources as the VM with normal shares. Now, there's an important word that I mentioned there. Entitled. So here's the way I want you to think about resource entitlements on an ESXI host. Let's say that four of us walk into a room and there's an eight-cut pizza. We're each entitled to two pieces of that pizza, but that doesn't necessarily mean we're all going to eat two pieces of that pizza. That just means each of us is entitled to two pieces. We all have a normal number of shares, we all have equal shares of that pizza, and that's what we're entitled to. Now, I may be really hungry that day, and I may want three shares. And somebody else may have just eaten something and they might only want one share. Well, then there's no contention. There's no contention in that scenario. So I can have my three slices, and that person can have their one slice, and there's no contention. So our share structure doesn't matter. The share structure only matters when there's contention. If there's two of us who want three pieces, then our share structure is going to determine, "Nope, you're only entitled to two. "This is a time of contention, "you're only entitled to two slices of that pizza." That's exactly like the share structure of this virtual machine. So under normal circumstances, this virtual machine is entitled a certain amount of memory, based on how many VMs are running on this host, based on how much memory they're entitled to. This VM is entitled to a certain amount of memory, but that share structure is only enforced if this ESXI host is running low on memory. That's the only time the shares are enforced. So I think of shares like a safety net. I have 50 VMs running on this host. They can all use all of the memory or CPU that they're configured with. This virtual machine's configured with two CPUs. It can use two full CPUs whenever it wants, it can have 'em. Unless other virtual machines are trying to get at those CPUs too. Unless there's not enough CPU resources to go round on the ESXI host, and then and only then is the share structure enforced. So it's basically like a safety net. We hope we don't have to use it, but if I have significant resource contention, it's there just in case. So that's CPU shares for a virtual machine, and memory is almost exactly the same. So memory I can set my share values for high, normal and low, and you can see those share values here, the number here is based on the amount of memory, so I configure this for four gigs of memory. The share numbers are based on that. So if I were to modify this virtual machine and give it eight gigs of memory, those share numbers get modified right along with it. So I can do high, normal or low, again just like with CPU, or I can actually input a custom value, but most of the time I don't recommend that, because things can get really funny really fast. Let's say that this VM, I want to give it a really high share structure. I'm going to give it a custom value, and I'll put in this big value here, something like that. You can do that, but I really don't recommend it, because then in this scenario, this VM can basically dominate the memory resources that it's granted. You'd probably be better off just giving it a reservation at this point. Because in this case, this virtual machine could potentially dominate the memory resources. So I try to just keep things as simple as I can. Stick with high, normal and low. That way you're not fooling around with going into virtual machines and manually modifying the share values that they are configured with. So those are shares, those are a concept that we'll also look at when we get into resource pools, but shares are a great way to configure relative priority during times of contention, and that's the critical concept of shares, is that they are only enforced when resource contention occurs.