• Edited by chome81 Friday, May 28, 2010 3:59 PM

Thanks for posting your question here.  Basically VMM uses a "slot" system to determine the number of VMs that can be placed on a cluster node before marking it as overcommitted.  Please see my response on the following thread:

http://social.technet.microsoft.com/Forums/en-US/virtualmachingmgrhyperv/thread/0e571138-1704-4458-9744-3916e2c0ef64

------------------------------------------------------

Best Regards, Mike Briggs [MSFT] – Posting is provided "AS IS" with no warranties, and confers no rights

Mike,

I believe I figured out how to correctly apply the formula you posted, however, I had an interesting result.  After using the formula I determined that if I lower one of my 4 GB RAM VM's down to 2 GB, I would then be able to create a new 2 GB VM.  That held true.  After completion, as a test, I bumped that first VM back up to 4 GB of RAM expecting that to put the cluster in an overcommitted state, it did not.  The cluter state is OK.  In addition to that, I bumped on of my 1 GB VM's up to 2 GB, still OK.  Any idea how that could be?

VMM appears to weight online versus offline VMs differently when performing this calculation.  That is a bug that we filed recently.  So that may have had an impact when you were performing the above test.

___________________________________________________________________________________________

Best Regards, Mike Briggs [MSFT] – Posting is provided "AS IS" with no warranties, and confers no rights

• Edited by Mike Briggs [MSFT]Microsoft employee, Moderator Tuesday, June 01, 2010 2:45 PM improved answer

Thanks Mike.  I discovered that while I was researching this issue.  In my particular situation all my VM are online, so this wouldn't be causing my issue.

Below is my current configuration as of Monday morning.  I'm going to apply the calculation with your formula.

1.  Find out the HAVM with the largest RAM.  Let's call this slot size.

Answer:  4 GB

2.  Calculate number of "used slots" on each host.

Answer:

HOST 1

Slot 1 - 4 GB VM

Slot 2 - 4 GB VM

Slot 3 - 1 GB VM and 1 GB VM

HOST 2

Slot 1 - 4 GB VM

Slot 2 - 4 GB VM

Slot 3 - 2 GB VM and 1 GB VM

Each host has 3 "non- empty" slots

3.  Caluclate the number of "free slot" on each host: (AvailableMemory - HostMemoryReserve - StoppedVMMemory - SaveVMMemory)/Slot Size

Answer:

HOST 1 - (11.22 GB - .5 GB - 0 - 0)/4 = 2.68

HOST 2 - (12.53 GB - .5 GB - 0 - 0)/4 = 3

4.  My cluster reserve is set to "1"

Does this not mean I should be in a "overcommitted" cluster configuration at this point in time?

• Edited by chome81 Tuesday, June 01, 2010 6:00 PM typo

Basically you need the number of free slots in the cluster to be greater than the number of slots in a particular host for the cluster to not be overcommitted.  If the number of free slots is less than the total number of slots in a particular host, then the cluster is overcommitted.

1)    HAVM with the largest amount of RAM: 4 GB = slot size

2)    Number of available slots per host: 5

a.     24GB - .5GB / 4 GB = 5.875

3)    Host_1 has 4 “used: slots, Host_2 has 4 “used” slots

4)    Host_1 has 1 “free” slot, Host_2 has 1 ”free” slot

5)    Host reserves is 1, number of slots in the host is 5

Total number of “free” slots in the cluster is 2 and is smaller than the number of slots in the host (5). The cluster is overcommitted. 

If you have any questions about this, please send me a direct email (mbriggs@microsoft.com) with your contact information and we can discuss offline.

__________________________________________________________________________________

Best Regards, Mike Briggs [MSFT] – Posting is provided "AS IS" with no warranties, and confers no rights

• Marked as answer by Mike Briggs [MSFT]Microsoft employee, Moderator Thursday, June 03, 2010 9:44 PM

Basically you need the number of free slots in the cluster to be greater than the number of slots in a particular host for the cluster to not be overcommitted.  If the number of free slots is less than the total number of slots in a particular host, then the cluster is overcommitted

I don't want to beating a dead horse in this oldish thread, but if VMM calculates slots based on the largest VM, isn't that a huge problem?

Let's say I have two hosts with 48GB each; pretty standard these days. I have VM's that are 4GB typically, but one that is a 16GB hog. I'd expect to be able to run about eight 4GB HAVM's plus the fat 16GB one.

But if 16GB is 1 'slot' each server only has two slots and if one on each is "reserve", then I can run 1 additional VM's (one!). I know we're always pointing out the bad things of memory overcommit, but this massive underutilisation is al lot worse if you ask me. Out of the total of ~96 GB I could only use 20.

VMM should be way more grannular in how it calculated (over)commitment of the cluster.

George.

Thanks for the feedback George.  I can assure you that this feedback has been passed along to the product team.  If you would like to discuss this further, please contact me at mbriggs@microsoft.com and we can schedule a time for a quick call.

__________________________________________________________________________________

Best Regards, Mike Briggs [MSFT] – Posting is provided "AS IS" with no warranties, and confers no rights

I would like to take this discussion a bit further and talk about a cluster with more than 2 hosts, maybe 4. Recently my cluster was alerting as being over-committed which led me to the article on MS which helped me in learning about the slot sizes and reservers and so on. I have since done some house cleaning and removed VMs that were not needed. Currently my cluster is ok but I wanted to dig deeper into my VM placement. Here is how my current environment looks, with a slot size of 8GB for the cluster

Node                   Used Slots                      Free Slots             Total Slots

N1                            5                                  1                          6

N2                            3                                  4                          7

N3                            4                                  3                          7

N4                            5                                  2                          7

Now, using the article I found on MS (kb2463008) If I were to use N2 as my cluster reserve number in the event of a failure I would have 6 free slots with a requirement of 7 and would be over commited. If I were to choose N3 as my cluster reserver host which also has 7 total slots and emulate that node failing I would have 7 free slot remaining in the cluster and 7 as the required number of slots. Cluster should not be over committed.

Is it safe to say that when running through these calculations, I need to determine the end result for losing any one of N1, N2 or N3?

Sorry if this is confusing, but how do you put confused thoughts into text in a clear manner! :)

Also, where is the SCVMM 2008 R2 over commitment calculator?? Would love it if someone at MS wrote one up like the Exchange and DPM workbooks.

Chris 

I have also an issue with these over-committed messages. I've done some digging around in the documentation and found KB2463008 as well. I've messed around with Powershell creating a kind of script that would show me my values.

Until Wednesday I was running a six-node cluster, running 140VM's. Wednesday the SCVMM was indicating the cluster was overcommitted. Later that day I added another node (not to avoid the overcommitted message; I just needed extra capacity on this cluster). Cluster remains overcommitted

Allow me to illustrate how the environment is looking right now.

I've got 6 equal nodes with 96GB RAM. My largest machine is 8GB. This should result in 11 or 12 slots (depending if you subtract the 0.5GB cluster reserve to determine the total amount of slots. Subtracting (as in this example) would give me another 7.5GB breathing room for othe processes). 

vMachines are spread over all hosts, giving following data:

This would mean if Node 2 or 3 would fail I would need 11 slots. If I count the free slots of the remaining nodes, I count 19 free slots. This should give an "OK" status, but in fact it's giving an "Over-committed" state.

I've got a little kind of algorithm to calculate how the slots are filled, resulting in (roughly) the same values (I've done the math by hand as well, but still the same).

I've tried clearing the CommitState on the SQL DB manually, but at the next host refresh the Over-Commited state returns.

Anyone an idea what's wrong with my configuration?

Tnx

Timo

Basically you need the number of free slots in the cluster to be greater than the number of slots in a particular host for the cluster to not be overcommitted.  If the number of free slots is less than the total number of slots in a particular host, then the cluster is overcommitted

I don't want to beating a dead horse in this oldish thread, but if VMM calculates slots based on the largest VM, isn't that a huge problem?

Let's say I have two hosts with 48GB each; pretty standard these days. I have VM's that are 4GB typically, but one that is a 16GB hog. I'd expect to be able to run about eight 4GB HAVM's plus the fat 16GB one.

But if 16GB is 1 'slot' each server only has two slots and if one on each is "reserve", then I can run 1 additional VM's (one!). I know we're always pointing out the bad things of memory overcommit, but this massive underutilisation is al lot worse if you ask me. Out of the total of ~96 GB I could only use 20.

VMM should be way more grannular in how it calculated (over)commitment of the cluster.

G

Please keep in mind that VMM is very conservative when determining whether or not a cluster is overcommitted.  We decided to err on the side of caution in this case :)  We definitely appreciate your feedback and suggestions.

There are only two workarounds that I have found, and to be perfectly honest neither are what I'd consider optimal.

1. Reduce the RAM allocated to the largest VM across the cluster.  In the above example that would be reducing the VM with 64GB.

2. Add additional nodes to the cluster.

Like I said, neither are optimal, but will provide some relief.

______________________________________________________________________________________

Best Regards, Mike Briggs [MSFT]  -- posting provided "AS IS" with no warranties and confers no rights

Hi There,

A question on all the above that hasn't been asked yet.. what does being "over committed" actually mean realistically?

I have the same problem as most, a large VM creates a large slot size, thus reducing the number of slots available in the cluster, etc etc.. causing an "over-committed" cluster.

However, I only require capacity to allow a single host faiure - doesn't this just mean i need enough spare memory to accomodate the VM's on any host that may fail? in the simplest terms, a completely empty host in the cluster with equal or more RAM?

Or is there something else behind the scenes that i need to take into account when a host fails?

Cheers,

Matt

Matt,

I think that could potentially work- given what I have read above, however, what should I do if adding another host to the environment is not an option?

Maybe this is a rookie question, but to add another host would require another physical matching host? With the particular customer I am working with, this isn’t something he wants to do because he just purchased 3 new HP ProLiants to host. Which was meant to replace all of the old systems.

Do you have any other advice? I am very open to suggestions!! J

Hey,

I wasn't suggesting that adding a host is required - i'm suggesting that a cluster that is showing as over-committed may not really be a problem, assuming you have enough spare memory in your hosts to run every VM IF one of the hosts fails.

i.e. can you migrate all your VM's off of one of your host and everthing fits on the remaining hosts? Then i believe you'd have sufficient capacity to cater for a host failure - regardless of whether VMM is showing the cluster as over committed.

note: i am just suggesting this as it seems logical to me, i'm seeking confirmation by someone.

cheers,

Matt

In a previous thread, I got Microsoft to finally recognize that the formula they use to determine overcommit was, in deed flawed and will be fixed in a future release.   Unfortunately, SP1 wasn't that release.

In my case, I had a 4-node cluster, all with 100% identical nodes.   1 node was always left empty, yet my cluster was still showing over-committed.   Proof that their formula is a bad one.

I have accepted the flaw and moved on, hoping to some day, get a fix.

I wanted to update this thread to point people to a blog entry which details how we've addressed this in VMM2012.

http://blogs.technet.com/b/scvmm/archive/2012/03/27/system-center-2012-vmm-cluster-reserve-calculations.aspx

Cheers, Hilton

Hello,

I have a 8-nodes cluster of Hyper-V hosts. I am running SCVMM 2012 R2 with UR 5.

SCVMM shows this cluster Over-committed most of the times. I have to manually migrate the VMs.

So, is there any easy way to determine which node of my cluster is Over-committed?

Thank you.

Regards,

Hasan Bin Hasib

• Edited by Hasan Bin Hasib 12 minutes ago

Hello,

I have a 8-nodes cluster of Hyper-V hosts. I am running SCVMM 2012 R2 with UR 5.

SCVMM shows this cluster Over-committed most of the times. I have to manually migrate the VMs.

So, is there any easy way to determine which node of my cluster is Over-committed?

Thank you.

Regards,

Hasan Bin Hasib

• Edited by Hasan Bin Hasib Monday, February 16, 2015 11:22 AM