Tuesday, October 16, 2012

Recently there was a need to quickly report the number of VMs in all VCs, ideally with numbers for powered on and powered off VMs. We have multiple VCs (10 plus), not in linked mode, so it meant connecting to each and counting or exporting the information.

It’s fairly easy to get this information, but figured a script may be in order, in case the request was made again in the future, so this is what I came up with. It’s rough and ready, but did what I needed it to do. And yes, there are other scripts and tools (RVTools, PowerGUI with the VMware powerpack etc) that can do it, but this is partly an exercise in trying to get to grips with Powershell and PowerCLI.

It also spits out a couple of CSV files with a basic host report and VM report per VC in files named per VC. Assumes credentials are sorted in some way for conveniance - ie, credentials store.

Monday, October 15, 2012

In our environment, we have a lot of VMs on NAT’d addresses. On occassion, I need acccess to their public IP - eg, for pinging to verify guests are still running if we put a host into maintenance mode. Grabbing the address from the internal system for each VM is time consuming and somewhat annoying. vSphere reports the private IP in the GUI which isn’t what I want. You can extract the info from the VM with PowerCLI, but again, it’s a little awkward (for my skill level). And we don’t label the VMs by their DNS name, it’s more an internal system, which again, makes identifying a particular machine harder than I would like, but that’s the way the system is.

Luckily, when we create VMs, we add annotations. One of which contains the public IP (or it should if people fill in the details :-)

That allows a way to grab the public IP with a one liner (here the assumption is the annotation field is called Public IP).

Recently started a new position, as a VMware guy in a managed service provider.

There are various challenges involved (mainly process oriented), but one challenge is scale. It’s a much larger environment than I had previously administered.

So, it means different ways of doing things, and makes me appreciate more the value of automation and the use of PowerCLI.

Problem is, I suck at coding. Always have, always will. But still, I feel I need to do it to make the role manageable. So, I’m going to start posting some bits and pieces I’ve been writing to try and help me and solve problems as they arise or as I see them. The code will almost invariably suck, but hey ho.

I use a lot of the “standard” resources. Google, Alan Renouf’s site, the PowerCLI book (I have it through my OReilly Safari account). Pretty much anything I do has (almost certainly) been done before (and better), but future entries will have some of my dabblings (primarily for my reference).