• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

das.slotCpuInMHz and das.slotMemInMB

Duncan Epping · Nov 18, 2010 ·

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.

Share it:

  • Tweet

Related

Server ha, high availability, VMware, vSphere

Reader Interactions

Comments

  1. sketch says

    18 November, 2010 at 13:45

    okay – NOW my head hurts. I’ll have to read this again and again and again…

  2. Fred Peterson says

    18 November, 2010 at 15:13

    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.

  3. Brandon says

    18 November, 2010 at 18:46

    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! 😉

  4. Fred Peterson says

    19 November, 2010 at 15:54

    @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.

  5. Duncan Epping says

    19 November, 2010 at 16:09

    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.

  6. Fred Peterson says

    19 November, 2010 at 16:23

    huh, I thought it still kept track of things for startup on other hosts. Guess I should reread some docs.

  7. Brandon says

    19 November, 2010 at 19:31

    @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.

  8. Graham says

    26 November, 2010 at 03:07

    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?

  9. Duncan Epping says

    26 November, 2010 at 16:44

    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

  10. Jonas says

    28 November, 2011 at 11:45

    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

  11. Duncan says

    28 November, 2011 at 12:04

    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.

  12. JOnas says

    5 January, 2012 at 16:16

    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

  13. bas says

    27 June, 2013 at 17:08

    should be das.vmCpuInMhz

    • bas says

      27 June, 2013 at 17:09

      I Meant: das.vmCpuMinMhz

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the HCI BU at VMware. He is a VCDX (# 007) and the author of multiple books including "vSAN Deep Dive" and the “vSphere Clustering Technical Deep Dive” series.

Upcoming Events

06-Feb-20 | NE-England VMUG | Newcastle
17-Feb-20 | Qatar / Oman / Dubai VMUG Tour
05-Mar-20 | Iceland VMUG | Reykjavik
19-May-20 | VMware GSS Tech Summit, Ireland
4-June-20 | VMUG Romania | Bucharest

Recommended reads

Please note, as an Amazon Associate I earn from below qualifying purchases.

Sponsors

Click to become a sponsor

Copyright Yellow-Bricks.com © 2019 · Log in