I was reading some threads on the VMTN forum and noticed a question on an advanced HA setting called “das.slotMemInMB”. The setting is briefly mentioned in my deep-dive, but after re-reading the section I think I could have been more clear in describing what is does, how it works and when to use it. Of course anything that goes for das.slotMemInMB also goes for das.slotCpuInMHz.
This is what I added to the deep-dive but I also wanted to share it through a regular blog to give it a bit more attention:
The advanced setting das.slotCpuInMHz and das.slotMemInMB allow you to specify an upper boundary for your slot size. When one of your VMs has an 8GB reservation this setting can be used to define for instance an upper boundary of 1GB to avoid resource wastage and an overly conservative slot size. However when for instance das.slotMemInMB is configured to 2048MB and the lowest reservation is 500MB then the slotsize for memory will be 500MB+memory overhead. If a lower boundary needs to be specified the advanced setting “das.vmMemoryMinMB” or “ das.vmCpuMinMHz” can be used.
okay – NOW my head hurts. I’ll have to read this again and again and again…
So I think I get it: When you have multiple VMs in the HA scenario, a slot size by default ends up becoming the VM with the highest *reservation*
So based on the deep-dive if you have two VMs one with 1GB reserved and the other with 2GB, the slot size for HA calculation goes with the 2GB value.
However if you use the das.slotMeminMB you can force HA to ignore the VMs reservation sizes so HA can recalculate slot sizes. This would likely make sense when you have a few VMs with reservations but majority do not, but with slot sizes calculated off the reservation sizes you could quickly screw with how HA handles load distribution and it would likely be unfair.
I dislike having to set advanced HA options except where explicitly needed (das.failuredetectiontime for instance), so I’ve always avoided per VM reservations as a practice.
See What Duncan put it the HA deepdive:
“Basic design principle: Be really careful with reservations, if there’s no need to have them on a per VM basis don’t configure them.”
Agreed! However, I’m also a bit torn allowing the slot size to be the minimums as well especially when using something like DPM. The minimum slot sizes allow for a metric ton of slots even on mid-sized hosts. 256mhz and 0mb of memory + overhead isn’t much. I usually pick a good VM candidate and set reservations there to define my slot size opposed to setting advanced options.
@Fred, load distribution? Maybe you’ve got DRS and HA confused. You certainly would limit the number of slots in your cluster with any “large” reservations set on a VM, and good design would keep you from changing the HA settings to allow violating admission control. You might make it hard to turn on all your VMs, or at least new ones :).
This is where the resource pool pie paradox stuff drives me crazy, because I would much prefer to use reservations on resource pools (or vApps) and not have to worry about the share counts. That makes MY head hurt. This stuff is complicated and I’ve seen many messed up environments because the admins didn’t understand the fallout from doing something simple, like a VM reservation. Someone somewhere gets a phone call: it won’t let me power on any VMs! 😉
@Brandon
No, I’m thinking about an actual HA scenario where a host has gone kaput and the VMs are being fired up on other hosts. Thats what I mean when I say load distribution.
Couple of things here before we all get confused:
1) HA doesn’t handle Load Balancing. It just tries to power on VMs in a “round-robin” like approach as of 4.1 to avoid overload on hostd and to increase speed of recovery and increase scale
2) das.slotMeminMB is to specify the max slotsize, however if no VM has a reservation the lowest possible slotsize will be selected
3) Avoid all this crap by selecting the percentage based admission control policy! it is way more flexible than any of the other options… and it even allows you to set a reservation on every single VM without the need to resort to advanced settings.
huh, I thought it still kept track of things for startup on other hosts. Guess I should reread some docs.
@Duncan, I agree on the percentage based admission control policy. It’s the best one :>, although I was specifically keeping things in context with your post which involves slot sizes. Using the percentage based policy removes that concern all together. Everyone here should read your deep dive, because it certainly clears up a lot of misconceptions people have, and for people like me, it even has pictures.
I have just found a slight issue:
If you have a VM with a 2G reservation and das.slotMemInMB is set to 1024 all looks good the slot size for RAM is 1024+ overhead, which matches what you have. If adding das.slotCpuInMHz to 1024 as well even though the current CPU slot size is 256 the das.slotMemInMB gets ignored and reverts back to what the largest reservation is set to.
Any ideas why this would happen?
It is an UPPER boundary and not a minimum. The name is misleading indeed. But if you want your CPU Slotsize to be 1024 at minimum you should add:
das.vmCpuMinMHz
Hi Duncan
Realy helpful blog, thank’s for your work! 🙂
Slotsize:
Where have I to put this in?
->Advanced Options (HA)
or
->Advanced Options (vCenter Settings)
I tryed both at it doesn’t work for me.
->Do I need to restart the vCenter Service?
Thank you very much
You will need to add it to the HA Advanced Options. But you will probably need to do a “reconfigure HA” for each of the hosts.
Hi Duncan
(I know, it’s a bit late 🙂
Thank you for your answer.
Sadly, it dosn’t work in my cluster. I tried two options
1. reconfigure HA for each host
2. deactivation of HA, and reaktivation of HA
In both cases, I have the problem, that my own settings (2000mhz and 4096MB ram) are ignored from HA.
Do you have any idea, what I’m doing wrong?
Thank you very much
Jonas
should be das.vmCpuInMhz
I Meant: das.vmCpuMinMhz