Awhile back a guy at the San Antonio VMUG asked the technical group how you could get the actual LUN UUID for a particular Datastore. I informed him that it was available via the PowerCLI and to contact me via the VMUG forums. He never did. My storage guy at work loves this script, though, so I thought I’d share it with everybody.
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.
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.
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.
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?
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.
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.