When you do over-provisioning on ESXi host, on memory, and CPU, you basically need a tool that makes sure that the VMs get the correct amount of resources. Let's say we have a VM that needs to get 3500MHZ (Reservation) and make sure that another VM for testing never gets more than 1000MHZ (Limit).
The basic understanding of reservation and limits will allow you to understand better the mechanism behind which vSphere uses to run your VMs and you'll learn with this topic to pass your VCP certification exam.
Our VCP-DCV Certification page has all the objectives needed from the VMware Blueprint. Find other chapters on the main page of the guide – VCP7-DCV Study Guide – VCP-DCV 2021 Certification.
Reservations is a resource guarantee on CPU or Memory, for a VM. When ou set a reservation you basically guarantee that particular VM gets this over a VM which does not have this reservation. You define reservation in MB or MHZ depending on which resource you make reservations for.
- The exam duration is 130 minutes
- The number of questions is 70
- The passing Score is 300
- Price = $250.00
Example 1: You have a virtual machine configured with 4 GB memory and you configure a 2 GB reservation. When the virtual machine powers on a 2 GB swap file (.vswp) is created on a datastore. The 2 GB reservation guarantees that the VM will always a least get 2 GB of physical memory. If the ESXi host is running low the remaining 2 GB can come from the swap file on disk.
Example 2: You have a virtual machine configured with 8 GB memory and you configure a 8 GB reservation. When the virtual machine powers on a swap file with zero in size is created. The 8 GB reservation guarantees that the VM will get ALL its memory from physical memory and it will never do hypervisor swapping or ballooning.
That was for memory.
For a CPU, you basically guarantee the clock cycles. You guarantee the reservation in MHZ. Let's say you give a VM a reservation. It basically means that the vmkernel CPU scheduler will give it at least that amount of resources. If a VM is not using its resources, the CPU cycles are not wasted on the physical host.
Other machines can use it. What is happening that when you set CPU reservations, the system is making sure that a VM will always get access to the physical CPU in an over-committed environment.
You set a limit – the VM will never use more than you set on the limit. For memory or CPU. It's pretty restrictive and the opposite compared to a reservation. If you set the limit lower than the configured memory for a VM, the particular VM will swap and ballon to have enough memory to run. But the performance will struggle, obviously.
Let's say that you have a VM which is configured with 8 GB memory and you configure a 2 GB limit. The VM guest OS will see 8GB of RAM, but the ESXi is not allowed to give it more than 2 Gigs of its physical RAM. When the VM will ask for more memory for running some apps, you'll see ballooning and swapping occurs.
When you set a limit for CPU, you basically limit the performance of a VM even if the ESXi has more than enough capacity on its CPU. It's a shame for this VM….
Shares define how much access you get to a resource compared to something else. Every virtual machine has 1000 shares configured pr. vCPU as a default. So you are already using them! All VMs are equal from a hypervisor perspective unless you change the shares and tell it which machines are really more important. What is important to know about shares is that they only are considered in case of contention! If you have available capacity for all machines it does not help performance to increase the shares on some machines.
Let's have a look at some examples.
Let's say that we have a VM (call this VM a VM01) that has 1000 shares and VM02 has 1000 shares and they are both competing for the same physical CPU core. So in this particular case, the ESXi CPU scheduler will give each machine 1/2 (50%) access and they will have the exact same performance.
Now, let's say what we have changed the config so now VM01 has 3000 shares and VM02 has 1000 shares and they are both competing for the same physical CPU core. We will see that VM01 gets 3/4 (75%) access and VM02 gets only 1/4 (25%) access.
When we again, change the config and our VM01 has now 3000 shares and VM02 has 1000 shares and they are not competing for the same physical CPU core. In this case, both machines will get 100% access to the physical CPU. It is because shares are only applied when we have a contention.
Find other chapters on the main page of the guide – VCP7-DCV Study Guide – VCP-DCV 2021 Certification.
VMware Direct download/buy links:
- VMware vSphere 7.0 Essentials PLUS
- VMware vSphere 7.0 Essentials
- VMware vSphere 7.0 Enterprise PLUS
- vSphere Essentials Per Incident Support
- Upgrade to vSphere Enterprise Plus
- VMware Current Promotions
More posts from ESX Virtualization:
- vSphere 7 U2 Released
- vSphere 7.0 Download Now Available
- vSphere 7.0 Page [All details about vSphere and related products here]
- VMware vSphere 7.0 Announced – vCenter Server Details
- VMware vSphere 7.0 DRS Improvements – What's New
- How to Patch vCenter Server Appliance (VCSA) – [Guide]
- What is The Difference between VMware vSphere, ESXi and vCenter
- How to Configure VMware High Availability (HA) Cluster
VMware Education (On Demand Courses)
- VMware vSphere: Install, Configure, Manage [v7] – On Demand
- VMware vSphere: Optimize and Scale [v7] – On Demand
- VMware vSphere: Install, Configure, Manage [V6.7] – On Demand
- VMware NSX-T Data Center: Troubleshooting and Operations [V2.4] – On Demand
- VMware vSphere: What's New [V6.7 to V7] – On Demand
- VMware vSphere: Optimize and Scale [V6.7] – On Demand
- VMware VCP Exam Vouchers – VCP exam vouchers may be used as payment for different VMware certification exams:
- VMware Learning Credits – Learning Credits provide the dual benefit of funding a well-trained IT staff, along with discounts options of up to 15 percent. Customers can schedule training when and how they need it. Customers can buy credits at the time of license purchase or as a stand-alone purchase