Virtually Jason

One of my customers called me for some help troubleshooting a backup issue.  For some inexplicable reason, their VM based backup solution was failing for a bunch of VMs on a specific ESXi host.  When I got there, the first thing that I checked was the host tasks and events.  It listed a whole bunch of failed vMotion attempts for one particular VM with no VM Tools installed, so I thought that I'd take a peak at the VM console to see what I could see.  That failed, with a fairly generic message: "Unable to connect to the MKS: Connection terminated by server" 9 times out of 10, that error indicates that there's a firewall between the ESXi host and the client.  It turns out that this was 1 time out of 10, because some subsequent network troubleshooting revealed that there was nothing odd going on in that space.  My next troubleshooting step was pretty obvious; check the ESXi host logs to see if anything stood out.  So, I logged into the local console of the ESXi server

Several of my customers use HP C7000 blade chassis for their ESXi hosts.  One of them asked me to help them update the firmware in their enclosures.  There are basically three different pieces of the blade chassis; each one needs updating.  The blades themselves need updating, the Interconnect Modules (basically, embedded switches) need updating and the Onboard Administrator Modules need updating.  There are different and varied steps for updating each of those components.  The blade is updated by bootstrapping with an SPP (Service Pack for Proliant) ISO.  The OA is updated through its own web interface by uploading a specific .bin file.  The Virtual Connect (which is the centralized management for all of the Interconnect Modules) is updated through its own special command line utility by uploading its own specialized .bin file. All of that is a little awkward, but it’s not really that big of a deal.  We did run into one spot of difficulty, as one of the BL460c ESXi hosts was report

One of my customers recently moved from standard vSwitches over to distributed vSwitches.  After performing the move, they deleted all of the standard vSwitches from the environment.  Unfortunately, a few weeks later it turned out that a few VMs had adapters that, for whatever reason, hadn't been moved over to the vDS and so I was tasked with finding any VM that might still be associated with the old (now deleted) standard vSwitches. This was an interesting challenge, as my normal approach to finding all VMs on a given vSwitch would be to simply loop through every host, get the specific vSwitch and then get all VMs on that vSwitch.  Since these vSwitches had already been deleted, that approach wouldn't work.  Eventually, I came up with this command: get-vm | % {if (($_ | get-virtualswitch).name -eq $null){$_.name}} This gets all of the VMs in the inventory.  For each VM, it then checks what vSwitch the VM is attached to.  I found that when the VM only uses a vSwitch that

This is another quickie (I've had a very PowerCLI rich couple of months!).  We've been doing a lot of mass ESXi host manipulations lately and typically grab the hosts in batches of 8.  As such, I've needed to be able to target a specific set of 8 ESXi servers with some of my PowerCLI commands.  The first 8 (named esx01-esx08) are really easy to grab with string matching: get-vmhost *esx0[1-8]* That command will return all ESXi hosts in that range.  That same trick doesn't work so well with other batches of ESXi hosts (until you get into the esx41-48 range), as the square brackets represent only a single character.  That means that get-vmhost *esx[09-16]* is not a valid construct.  Fortunately, this is a pretty easy match to make with a regular expression : esx(09|1[0-6]) That regex works because of a few important symbols.  The | is the key to it; it means "or".  A simple example would be "09|10" which matches anything with "09" or &q