Need some info please.
I have a host part of a DRS and HA Cluster. DRS set to manual at the moment for other reasons.
Host has 104GB of memory. One VM runs on this host. VM has 100GB vRAM
When trying to create a 100GB memory reservation for the VM I get the error that there is not enough memory available on the host. Why is that?
No other VMs running on the host. I also set the admission control to Disable: Allow VM power on operations that violate availability contraints.
Any help?
You are probably running into a situation where your VM's memory overhead requirement. What does the memory overhead reading on the VM's summary tab specify? I'll wager that that amount plus whatever ESXi's system overhead is going to be greater than 4GB, for a VM with 12 cores and 100GB. Look at PMEM/MB and see how much vmk is using; that is the amount of "mangement memory" being used (not VM related).
Next question: if this is the only VM that will be running on the host, then why are you bothering creating a reservation?
I suspect you are exceeding the limit because of the memory overhead. How many vCPU's does the VM have allocated?
you have to consider the memory overhead + system overhead in your calculation.
Where can I see the current memory overhead and system overhead?
Via ESXTOP OVHD for the VM is 774, OVHD MAX = 840.
System overhead by that you mean memory used by system (service console in the older days)? That at the moment is 383.
So if you calculate all this you should still be able to give a reservation of 102GB? What am I missing?
Sorry, 12 vCPUs..
Anyone..
You are probably running into a situation where your VM's memory overhead requirement. What does the memory overhead reading on the VM's summary tab specify? I'll wager that that amount plus whatever ESXi's system overhead is going to be greater than 4GB, for a VM with 12 cores and 100GB. Look at PMEM/MB and see how much vmk is using; that is the amount of "mangement memory" being used (not VM related).
Next question: if this is the only VM that will be running on the host, then why are you bothering creating a reservation?
PMEM/MB = 2031 vmk
Memory overhead = 1.2GB
So all overhead = 3.9GB.
Now is starting to makes sense. Was cutting it way to close, didnt know about the PMEM/MB vmk value.
Well, we are struggling with SQL performance problems, and SQL prefers a memory reservation, even though ballooning wont take please since there is only one VM on the host?
With regards to your SQL performance problems, have you investigated your storage stack. I would take a close look at disk latency and disk queue lengths in the first instance (this along with the other usual suspects, RAM including virtual memory, processor queue lengths, and network output queue).
johanswa wrote:
PMEM/MB = 2031 vmk
Memory overhead = 1.2GB
So all overhead = 3.9GB.
Now is starting to makes sense. Was cutting it way to close, didnt know about the PMEM/MB vmk value.
Well, we are struggling with SQL performance problems, and SQL prefers a memory reservation, even though ballooning wont take please since there is only one VM on the host?
SQL prefers a memory reservation - Where did you get this idea from? Have you had Microsoft or someone who is an expert in SQL performance take a look at your environment? Keep in mind that just because "Task Manager" says sqlservr.exe is consuming, say 99GB of memory, doesn't mean that it is actually *using* that much memory... it is going to claim at a minimum what the SQL admin set as the minimum memory for the instance, and usually will grab much more, if it is available, for buffer space (call it cache for sake of discussion). When Windows encounters memory pressure, SQL will give some of that memory back.
I agree with jrmunday that you need to consider looking at your I/O. You might have some tweaks either in your storage system, or maybe you have an unoptimized query, or bad application code, or some indexes that need to be created, or something else that causes more I/O than necessary. Managing SQL performance is a complex undertaking that requires expertise from several IS diciplines to handle, at times.