Yellow Bricks

by Duncan Epping

4.1

Insufficient resources to satisfy HA failover level on cluster

· ·

I had this question yesterday where the error “Insufficient resources to satisfy HA failover level on cluster” comes from. And although it is hopefully clear to all of my regular readers this is caused by something that is called vSphere HA Admission Control, I figured I would reemphasize it and make sure people can easily find it when they do a search on my website.

When vSphere HA Admission Control is enabled vCenter Server validates if enough resources are available to guarantee all virtual machines can be restarted. If this is not the case the error around the HA failover level will appear. So what could cause this to happen and how do you solve it?

  • Are all hosts in your cluster still available (any hosts down )?
    • If a host is down  it could be insufficient resource are available to guarantee restarts
  • Check which admission control policy has been selected
    • Depending on which policy has been selected a single large reservation could skew the admission control algorithm (primarily “host failures” policy is impacted by this)
  • Admission Control was recently enabled
    • Could be that the cluster was overcommitted, or various reservations are used,  causing the policy to be violated directly when enabled

In most cases when this error pops up it is caused by a large reservation on memory or CPU and that should always be the first thing to check. There are probably a million scripts out there to check this, but I prefer to use either the CloudPhysics appliance (cloud based flexible solution with new reports weekly), or RVTools which is a nice Windows based utility that produces quick reports. If you are interested in more in-depth info on admission control I suggest reading this section of my vSphere HA deepdive page.

vCenter Extension error when deploying vSphere Replication?

· ·

I’ve seen this popping up fairly often now and was under the impression I wrote about it a while back, but can’t find it. So here you go. If during the deployment of an OVF, in this case vSphere Replication, you hit a vCenter extension error it is probably due to a field missing in the vCenter runtime section of the vCenter settings.

The error which is shown in the log is:

“The virtual machine ‘<vm name>’ has a required vService dependency ‘vCenter Extension Installation’ which is not bound to a provider.”

It will show up in the UI with “No provider available” and “This dependency is required”. You can simply solve this by doing the following:

  • Open the vSphere Client
  • Go to “Administration” and “vCenter Server Settings”
  • Click “Runtime Settings”
  • Ensure both “Managed IP Address” (typically missing) and “vCenter Server Name” are filled out.
    vcenter extension error

Now the OVF should deploy correctly. Note that the “Managed IP Address” field is empty by default, so if you are deploying a new vCenter Server instance make sure to fill it out. This will help preventing from running into the vCenter extension error in the future when adding other services.

How do I configure an HA vpxd.das advanced setting?

· ·

On the community forums someone asked a question around how to set “config.vpxd.das.electionWaitTimeSec”. I was looking at the documentation and it is indeed not really clear on what / where / how to set an HA vpxd.das advanced setting. This KB article kind explains it, but let me summarize it and simplify it.

There are various sorts of advanced settings, but for HA three in particular:

  • das.* –> Cluster level advanced setting.
  • fdm.* –> FDM host level advanced setting (FDM = Fault Domain Manager = vSphere HA)
  • vpxd.* –> vCenter level advanced setting.

How do you configure these?

  • Cluster Level
    • In the vSphere Client: Right click your cluster object, click “edit settings”, click “vSphere HA” and hit the “Advanced Options” button.
    • In the Web Client: Click “Hosts and Clusters”, click your cluster object, click the “Manage” tab, click “Settings” and “vSphere HA”, hit the “Edit” button
  • FDM Host Level
    • Open up an SSH session to your host and edit “/etc/opt/vmware/fdm/fdm.cfg”
  • vCenter Level
    • In the vSphere Client: Click “Administration” and “vCenter Server Settings”, click “Advanced Settings”
    • In the Web Client: Click “vCenter”, click “vCenter Servers”, select the appropriate vCenter Server and click the “Manage” tab, click “Settings” and “Advanced Settings”

By the way, this KB also lists all HA advanced settings that are relevant… might be worth reading as well. Hope this helps configuring your HA vpxd.das advanced setting.

Get your Kindle copy of the vSphere 4.1 HA/DRS Deepdive for free

· ·

I just sent out this tweet. Last time we did this promo many people said they somehow missed it and asked if we could do it again. We started the promo this morning, make sure to download it now as it will not be free (yes that is $ 0,-!) for long. Promo ends Thursday.

Special offer, the vSphere 4.1 HA/DRS Deepdive Kindle edition for FREE! vmwa.re/free41

Enjoy,

I set restart priorities but still my VMs seem to be powered on in a different order!

· ·

On the VMware Community someone asked this question about restart priorities. At the same time I received a question on a similar topic via email. This particular question was as follows:

I have restart priorities defined on my cluster. However even if I place my virtual machines for which this order applies on one host and test a failure they seem to come online in the wrong order…

In vSphere HA you can define the restart priority for each individual virtual machine. Now this restart priority applies to the power-on task that is initiated by HA when a host has failed. Did you note that I emphasized power-0n attempt? Well there is a reason for that… it is the prioritization of the attempt itself. HA doesn’t wait for a virtual machine to power-on before it starts the next… it just does the power-on attempt and when it completes the next round will be attempted. This also means that if you use 3 different priorities it could happen that a “low priority” virtual machine is restarted literally seconds after a “high priority” virtual machine is. In the case of the person who asked the question he had a large database machine defined as “high priority” and an app as “low priority”. Unfortunately the database machine took minutes to power-on and report up, where the application took less than a minute.

Keep that in mind when defining the restart priorities for your virtual machine. Yes it will help, but only for prioritizing which virtual machine needs to be restarted first. This is not a guarantee your virtual machines will be completed booted up first,