I think my cloud might be slightly over provisioned

VMware HA policy restricting VM deployment well before ESXi Hosts have reached capacity.

This can happen due to the default mechanic for slot size calculation in VMware HA.  The default slot size is calculated based on the size of your largest VM in the cluster, and in this example I’m talking about memory because that is generally the first HA bottleneck, not CPU.  If your like me and you have a single large 8GB VM and a bunch of small 256MB VM’s, your cluster admission policy will stop deployments even when ESX host memory usage is below 50%.  To increase your slot size, which you can see here:

You can see the Slot size is 8332 MB, I’d prefer it was down around 1024 to be closer to reality.

To make the change, go into the Advanced Options of HA

And set das.slotmeminmb to a value of 1024

Now when you go back and look at the current slot allocation “Advanced Runtime Info” you see that you have gone from 112 slots to 966

HA should again work as expected, but you should know that even though this will allow you to essentially overcommit your HA settings and HA working properly for your large VM in a disaster is no longer guaranteed due to the custom settings.

Here is the  text from the vSphere Availability Guide

Slot Size Calculation is comprised of two components, CPU and memory. 

VMware HA calculates the CPU component by obtaining the CPU reservation of each powered-on virtual machine and selecting the largest value. If you have not specified a CPU reservation for a virtual machine, it is assigned a default value of 256 MHz. You can change this value by using the das.vmcpuminmhz advanced attribute.)

VMware HA calculates the memory component by obtaining the memory reservation, plus memory overhead, of each powered-on virtual machine and selecting the largest value. There is no default value for the memory reservation.

If your cluster contains any virtual machines that have much larger reservations than the others, they will distort slot size calculation. To avoid this, you can specify an upper bound for the CPU or memory component of the slot size by using the das.slotcpuinmhz or das.slotmeminmb advanced attributes, respectively.

Isilon NFS load balancing & vCD 1.5 (cloud director)

Recently setting up an Isilon with the new scale vCloud we spent alot of time discussing what options we had to load balance across the Isilon nodes. The recommended best practice is to statically setup a matrix of multiple datastores to the separate nodes individually. However, two unique items about this setup prevent this from being overly useful. Our Isilon is presented as one large storage pool that isn't subdivided. The way vCD works, it fills the first pool, then moves onto the second one. Knowing these two things vCD would fill the first datastore, but then never move onto the second one. I decided to just use Smart Connect Basic features that come with the Isilon. The ESX servers will then use DNS to dynamically connect to the separate Isilon nodes.

Import ISO to vCD 1.5

I like to use the import from vSphere, it's alot faster than the upload an ISO function.  Also, it is less likely to fail than the ISO uploader because it doesn't copy to the vCD (vCell) server first, which is error prone due to issues like running out of disk space.