Since deploying the Nexus 1000v, it set our slot sizes in the cluster to 1.5GHz and 2GB of RAM. Not wanting to waste slots in our cluster by guests that may not reach that size (or partially fill slots), I wanted to carve out the cluster into slots of a lesser size, similar to using smaller block sizes on a drive to maximize space.

Using percentage reservations with vSphere, you can get by the slot sizes, but what if you’re starting a small cluster and growing it as resources are needed? How could I carve 25% out of a 2-node cluster? Sure, you can do it, but if you’re operating at the full 75% (with 25% reserved for failover) and lose a host, you actually don’t have enough resources and are over-committed by 25%.

Setting the following settings will help reduce your slot size, but may also have a negative impact by not having enough reservations if you end up in a failover state.

Lets face it, repetition sucks. When provisioning ESX hosts, using such things as the EDA make life easier, but it only does so much for ESXi.

The install for ESXi is simple and straight forward, but when done, you have to go and set everything else (IP, hostname, DNS, local users, etc…). Doing this for 20 hosts could be a PITA (Pain In The A..), so I set out on writing a script that does all of this for you.

All you have to do is set the IP & root password, then verify you can ping the host by it’s hostname (set host/A record in DNS). Once that’s verified, here’s what the script does for you:

Creates an Admins group and assigns it to the Administrator role

Creates local users, sets their default password, and adds them to the Admins group

Sets primary & secondary NTP & DNS servers

Sets DNS search suffix

Combines the provided hostname with DNS search suffix to populate the hostname FQDN

Sets EnableNaviReg to 0, disabled (requested by my storage team)

Disables iSCSI (disabled by default, but enabled in my sd image I created from previous post, thus the need to disable)

Disabled Tech Support Mode, aka ‘unsupported’ console

This is a slightly more advanced script, and it’s not fully polished, but works.

I wanted to expand This Script to allow you to specify hosts as well, instead of just vCenter.

This came about because we have 20 new hosts that need storage so we can build our new vCenter server on them, and my old script wouldn’t suffice.

I know you can rescan at the container level (cluster, folder, datacenter), but sometimes the processes would hang on large clusters, other times I’d have to rescan twice. I like this script because it rescans all HBAs one by one, then rescans VMFS after. One could probably add the -runasync, but then it’s the same as the right-click in vCenter.

When building a new cluster, your storage team (or you) may need to add several hosts into the shared storage zone. It’s a pain to go to each host, configuration, storage adapters, then copy out the WWN.

With this script, you can supply a vCenter server and Cluster/Folder/Datacenter (any logical container) and it will list all the WWNs for Fibre Channel devices. But what if you don’t have vCenter stood up yet? No problem, you can also supply a list of ESX/ESXi hosts to scan.

Shawn & I built this because we have 20 hosts we need the WWNs from to provide to our storage team, and vCenter isn’t alive yet.

We ran into an issue where we needed an entire SAN frame retired. Problem is, there are several datastores and several guests running on that frame.

I wanted to script it out, which worked just fine. Then, we had more to do, so I edited the script and ran it again. After the third or fourth time, I decided to write a script that takes params via the cli.

Make sure your datastore names are similar, for instance, mine appends ‘_New’ to the end. So my datastores have to be named like this: ‘vmdatastore’ and ‘vmdatastore_New’. It will get all guests on the datastore and migrate them one by one over to the new datastore. When done, just delete the old datastore (or rename it to _Old) and rename the new one to match.

We all hate that adding DDR3 sticks to a server slows down the QPI speed (or RAM Bus for lack of a better example).

That changes with the Nehalem EX proc (and perhaps Westmere), as the CPU governs the speed. You can throw up to 16 sticks of DDR3 RAM per CPU at either 800, 978, or 1066MHz, and the governing factor is the CPU: