Once you turn DRS on and set it to fully automatic, unless you have some affinity / anti-affinity rules in place, your VMs will get up and dance around your cluster. In most cases this is fine and dandy. However, occasionally there are times where you will want to know where the VM was, where it went, and when it went there (sort of like tracking a teenager who is out for the night).

To do that, you can check DRS History in the vSphere client:

@vRobM and I were discussing an unrelated topic when DRS and the mysterious stars came up.  (**)?  Our first instinct was this was the “special sauce” between the two all beef patties.  However after some creative KB searching we came across a formula that describes it quite well:

DRS Recommendations

To understand the stars, you need to understand where to find them and what they mean. The following is taken from the VI3 docs:

Priority for this recommendation, as a number of stars.  Five stars, the maximum, indicate a mandatory move because of a host entering maintenance mode or affinity rule violations. Other ratings denote how much the recommendation would improve the cluster’s performance; from four stars (significant improvement) to one star (slight).

So that explains what the stars indicate as far as recommendations go.  But what makes a 3 star and what makes a 4 star recommendation?

Calculating the Priority

Turns out that this isn’t exactly the special sauce we thought it was. Rather, there is some carefully reasoned out math that goes into this.  This KB article spells it out in detail, but we’ll hit the high points.  First the formula:

6 – ceil(LoadImbalanceMetric / 0.1 * sqrt(NumberOfHostsInCluster)).

There are two variables in there and only one of which is obvious, “LoadImbalanceMetric” however can be interesting:

LoadImbalanceMetric is the current host load standard deviation shown on the cluster’s Summary page of the vSphere Client.
For each host, compute the load on the host as sum(expected VM loads)) / (capacity of host). Then compute the standard deviation of the host load metric across all hosts to determine LoadImbalanceMetric.

So where does one find this standard deviation? Select your cluster, then summary and look for the following section:

In our particular case, not much to look at, as well, she is seemingly a well balanced cluster. However let’s work through the formula with the assumption that we have a 2 node cluster and a standard deviation of 0.282 (the “target” from above):

6 – ceil(0.282 / 0.1 * sqrt(2)).

What is Ceilias brother Ceil doing with my numbers?

Turns out, it is not a family of mathematicians busily flicking their abacus’.  ‘Ceil’ here, represents the Ceiling function, which I’m sure you’ve heard of before.

According to Wikipedia the Ceiling function is:

In mathematics and computer science, the floor and ceiling functions map a real number to the largest previous or the smallest following integer, respectively. More precisely, floor(x) = ⌊x⌋ is the largest integer not greater than x and ceiling(x) = ⌈x⌉ is the smallest integer not less than x.

So that works out as:

or:

6 – the smallest number not less than (0.282 / .1 * sqrt(2)) which equals 2, hence, a 2 star recommendation. (**)!

More info: Duncan Epping @ Yellow-Bricks has put together an excellent Deep-dive page for DRS, where you can get into much greater detail.

WolframAlpha to the Rescue

While this can easily be done in any random calculator (or in the heads of some folk) I used WolframAlpha to good avail.  It’s quick and gives you a graphical breakdown of the formula. Just plug in new values and go!

Summary

The recommendations and mathematical bits take place behind the scenes seamlessly.  After all, that is the magic of DRS.  However, it helps to have an understanding of the actual logic and math that goes into those recommendations so you can better understand your cluster, and better plan for new hosts and workloads.  As always drop a line in the comments or tweet to either @vRobM or myself on Twitter.

Update: Thanks for the excellent deep-dive page Duncan!

DPM or Distributed Power Management, is like VMware’s DRS on Steroids. It is the evolution of the DRS or Distributed Resource Scheduling concept. For those that don’t know what DRS is, I will do the needful and link the VMware Marketing Page for it. Here it is in a video:

Now that you get the basics of it, lets talk about what this means.  It means lower power utilization across all hosts. It means that the hippies on your door step will praise you, and that the Obama administration will hold you up on high for your cutting edge example of how you are helping the environment.

What it also means, is that in all likely hood you are powering up, and down servers that were designed to be powered on 100% of the time. This can potentially lead to more hard drive, and other failures. Hardware manufactures are testing against this now to ensure that it doesn’t do anything drastic to MTBF (Mean Time Between Failures). At the same time that are also working on other power saving technologies (speed stepping the processors, spinning down unused disks, memory enhancements, etc) that will also go a long way in this space.

So while it’s really cool (that’s a techie term right there), I would still strongly recommend testing it out before deploying it within your environment.

Two of them this time around:

VMSA-2008-0019 (The website does not appear to have a 0019, but the 0018 matches up with it)

Updated VMware Hosted products and patches for ESX and ESXi resolve
two security issues. The first is a critical memory corruption
vulnerability in virtual device hardware. The second is an updated
bzip2 package for the Service Console

VMSA-2008-0017.2

Updated ESX packages for libxml2, ucd-snmp, libtiff.

A denial of service flaw was found in the way libxml2 processes
certain content. If an application that is linked against
libxml2 processes malformed XML content, the XML content might
cause the application to stop responding.

The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CVE-2008-3281 to this issue.

Additionally the following was also fixed, but was missing in the
security advisory.

A heap-based buffer overflow flaw was found in the way libxml2
handled long XML entity names. If an application linked against
libxml2 processed untrusted malformed XML content, it could cause
the application to crash or, possibly, execute arbitrary code.

The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CVE-2008-3529 to this issue.