vSphere

ESXi Auto configuration script

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.

Using PowerCLI to rescan HBA and VMFS v2

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.

So, without further ado, here’s the updated script:

Using PowerCLI to rescan HBA and VMFS in a cluster

Having an ESX cluster is nice, and adding shared LUNs can sometimes become click redundant (host, config, storage, rescan; repeat).

Since we’ve been migrating to a new storage array, we’ve been adding quite a few LUNs to different clusters on different vCenter servers, so I wanted an easy way to rescan everything.

So here’s my script:

Mass Storage Migrations using vSphere Storage vMotion and PowerCLI

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.

My script:

vSphere Maximum Configuration – VMs per host limitations on Update 1

When planning a new virtualization environment, consolidation numbers are always flying around, and specifically the number of VMs you can run on a host.

According to This Doc you can have a max of 320 VMs per host, but keep in mind the number’s different for HA clusters. I was also pleased to find out the numbers were slightly changed for Update 1.

Fast deployment of vSphere ESXi 4.0 running on a 1GB SD-Card

When we’re ready to deploy new ESXi hosts in our environment, we order them from Dell with ESXi pre-loaded on the internal SD-Card. This is nice and all, but what do you do when you have to go through and configure NTP, Users, Groups, Scratch directory, lockdown mode, and the list goes on?

You’d have to fire up each server, go through and configure everything, x10 if you had 10 new servers.

Since we’re working on a new rather larger virtualization deployment, we were looking at ways to overcome this.

Cisco UCS Blade System – Part 3 – moar vSphere ESXi & UCS woes

Well, Cisco finally came with an answer to why I was able to break the stuff like clock work before, and that answer was firmware. A new firmware has been release for the chassis, blades, & FEX (and I’m sure I’ve either got that in the wrong order or hardware), but I can’t say I’m excited about it.

We set more time aside to have Cisco come in and upgrade the bits, as if we haven’t wasted enough time already. This time, they sent the big guns to work on it, or gun, rather, as they sent one of the engineers named Troy. He was a good guy, very knowledgeable, but he can’t help it that he works for Cisco, we’ve all gotta eat, right?

Cisco UCS Blade System – Part 2 – my vSphere ESXi & UCS woes

Okay, so now that we’ve tested different OS installations, now it’s time to test the real purpose we acquired these blades for: Virtualization

A little info on the hardware: Cisco N20-B6620-1, dual Xeon E5540s, 24GB of RAM, and two 73gb drives

We’re using VMware ESXi 4.0u1 for our testing, and booting from the SAN. Yes, I know, it’s only still experimental with vSphere, I don’t like it, but that’s the path I was lead down by my superiors.

Cisco UCS Blade System – Part 1 – drawing back the veil

We were some of the earliest of ‘adopters’ for a paid POC to get the Cisco UCS system in-house.

Cisco sent the hardware & a group of techs to get this thing off the ground. Any new hardware being deployed shouldn’t require a group of people from the vendor to come out to set it up, should it? In today’s society, it should be user friendly, plug-n-play, which we all know Cisco to be, right? Heh, okay, or not, but anyway, our trouble had just begun.