powershell

Finding WWNs for HBAs in multiple ESX or ESXi hosts, standalone or clustered

**Update May 07, 2012 – Use the new script here: Updated: Finding WWNs for HBAs in ESXi hosts, now with Get-VMHostHba

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.

Our 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:

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.

ThepHuck

powershell