Yellow Bricks

by Duncan Epping

drs

What’s new in vSphere 5.5 for DRS?

· ·

In vSphere 5.5 a couple of new pieces of functionality have been added to DRS. The first one is around the maximum number of VMs on a single host that DRS should allow. I guess some of you will say hey didn’t we introduce that last year with that advanced setting called “LimitVMsPerESXHost“? Yes that is correct, but the DRS team found this too restrictive. They’ve added an extra setting which is called LimitVMsPerESXHostPercent. A bit smarter, and less restrictive… so how does it work?

Basically LimitVMsPerESXHostPercent is LimitVMsPerESXHost in a more dynamic way as it automatically adjusts the limits. When you set LimitVMsPerESXHostPercent to 50 in a 4 host cluster which is running 20 VMs already and you want to poweron 12 new VMs. How many VMs can a single host run?

32 total VMs, 4 hosts --> mean: 8 VMs per host

We set the percentage to 50 so the new limit is 8 + (50% * 8) = 12

So if host 1 was only running 2 VMs, it can now take on an additional 12 without the need for you to constantly change the LimitVMsPerESXHost when you introduce new VMs. LimitVMsPerESXHostPercent does this for you.

Latency Sensitive Workloads

As of vSphere 5.5 DRS recognizes VMs marked as latency-sensitive (vCenter Web Client option). With 5.1 it could occur that latency sensitive VMs were moved around by DRS, as you can imagine when a VM migrates this will impact which ever application is running. Although the impact is typically little, for a latency sensitive workload even “little” could be disastrous. So in order to avoid this unwanted impact DRS treats latency sensitive VMs as if they have soft-affinity to the host they are running on. But what when there is an absolute need to migrate this VM, well as mentioned it is “soft affinity”, so treated like a “should rule” and in that case it means that the VM can be moved when needed.

Do note that within the DRS UI you don’t see this affinity anywhere, this is solved within DRS itself. Awesome and needed if you ask me!

Another one

Last but not least another new advanced option, this option is titled “AggressiveCPUActive“. When you set it to “1” DRS will be more aggressive when it comes to balancing VMs when %RDY is impacting them. This can be useful in environments where %RDY has a very spiky behaviour. AggressiveCPUActive will help avoid averaging out the bursts and will allow for DRS to aggressively balance your virtual infrastructure. (Official explanation: AggressiveCPUActive, when set to 1, causes DRS to use the 80th percentile of the last five 1-minute average values of CPU activity (in other words, the second highest) to predict the CPU demand of virtual machines in the DRS cluster, instead of using the 5-minute average value (which is the default behavior). This more aggressive DRS behavior can better detect spikes in CPU ready time and thus better predict CPU demand in some deployments.)

DISCLAIMER: I do not recommend using advanced settings unless there is an absolute need for it. I can see why you would use the “LimitVMsPerESXHostPercent” but be careful with “AggressiveCPUActive“.

Reminder: Free Kindle copy of vSphere 5 and 4.1 Clustering Deepdive

· ·

Just a reminder, if you want your free Kindle copy of the vSphere 5.0 Clustering Deepdive or the vSphere 4.1 HA and DRS Deepdive, make sure to check Amazon (US Kindle Store) today and tomorrow (Wednesday June the 5th and Thursday June the 6th)! You can download the Kindle copy of both these books for free, yes that is correct ZERO dollars.

So make sure you pick it up either before the promo expires…

** Note I have linked the US Kindle stores, it is also available for free in local Kindle stores, just do search! **

 

Manual vMotion and using DRS to select a host results in no migration?

· ·

I had a question from a customer last week. He was doing a manual migration on a cluster which had DRS enabled. He was using the vSphere Web Client and was wondering if he should tick the “Allow host selection within this cluster” tickbox or not, as shown in the screen shot below. The customer decided not to tick the “host selection” tickbox and decided that DRS would pick the right destination for the virtual machine. After he clicked “Finish” he noticed that the “relocation” literally finished in seconds and he wondered if anything happened at all… When he looked at the virtual machine he noticed it was still located on the same host, how can that be?

Well the answer is fairly straight forward, in this case the DRS cluster was balanced and that is the typical situation for most clusters out there I would say. When initiating the vMotion workflow the Cluster was selected as a destination so DRS had to figure out what the best destination would be. Considering the cluster was in balance, there would be absolutely no point in moving this virtual machine so what did DRS decide? Indeed, destination = source.

If you are going through this workflow using the Web Client, make sure to tick “Allow host selection within this cluster” and select a destination other than your source… otherwise the effort was pointless.

Manual vMotion

Free Kindle copy of vSphere 5.0 Clustering Deepdive?

· ·

Do you want a free Kindle copy of the vSphere 5.0 Clustering Deepdive or the vSphere 4.1 HA and DRS Deepdive? Well make sure to check Amazon next week! I just put both of the books up for a promotional offer… For 48 hours, Wednesday June the 5th and Thursday June the 6th, you can download the Kindle (US Kindle Store) copy of both these books for free, yes that is correct ZERO dollars.

So make sure you pick it up either Wednesday June the 5th or Thursday June the 6th, it might be the only time this year it is on promo.

DRS not taking CPU Ready Time in to account? Need your help!

· ·

For years these rumors have been floating around that DRS does not take CPU Ready Time (%RDY) in to account when it comes load balancing the virtual infrastructure. Fact is that %RDY has always been a part of the DRS algorithm but not as a first class citizen but as part of CPU Demand, which is a combination of various metrics but includes %RDY. Still, one might ask why %RDY is not a first class citizen.

There is a good reason though that %RDY isn’t, just think about what DRS is and does and how it actually goes about balancing out the environment, trying to please all virtual machines. Yes a lot of possibilities indeed to move virtual machines around in a cluster. So you can imagine that it is is really complex (and expensive) to calculate what the possible impact is after a virtual machine has been migrated “from a host” or “to a host” for all of the first class citizen metrics.

Now, for a long time the DRS engineering team has been looking for situations in the field where a cluster is balanced according to DRS but there are still virtual machines experiencing performance problems due to high %RDY. The DRS team really wants to fix this problem or bust the myth – what they need is hard data. In other words, vc-support bundles from vCenter and vm-support bundles from all hosts with high ready times. So far, no one has been able to provide these logs / cold hard facts.

If you see this scenario in your environment regularly please let me know. I will personally get you in touch with our DRS engineering team and they will look at your environment and try to solve this problem once and for all. We need YOU!