Finding vCenter when it's Down

We’ve all probably been in this situation: vCenter has experienced a catastrophic failure and isn’t even responding to ping, so you need to get console access in order to resolve the issue.  The challenge is that the VM could be running on any of 16 ESXi hosts in your cluster.  Generally, I like to create DRS Host Affinity rules for the vCenter and its SQL server so that I know which host those VMs should be running on during normal operations, but if HA has been busy they could still be anywhere.  That means that you need to find those VMs in order to troubleshoot, which could take a while.  Instead of opening 16 vSphere Client instances, each connected directly to an ESXi host in your environment, there’s a much easier way to find those VMs: PowerCLI!

PowerCLI can query a whole array of ESXi servers fairly quickly, returning the host(s) that you need to log the vSphere Client into in order to fix things.  To do this, you’ll need to change your PowerCLI instance to allow multiple VIServer connections:

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Scope Session

After that, you can connect to all of your ESXi hosts.  If you’re uncomfortable with typing your root password into a command, you can leave that option out and just supply it when challenged by each host.

connect-viserver @("esx1","esx2","etc") -user root -password Password

Alternately, you can get creative with VICredentialStoreItems and connect like this:

1..6 | % {new-vicrednetialstoreitem –host “esx$_” –user root –password Password}
connect-viserver @("esx1","esx2","etc")

Next, you can query all of the ESXi hosts for the desired VMs:

(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost

That first command will report the host that is running a VM called “vCenter01” and the second command will return the host that is running a VM called “SQL01”.  You’ll probably have to change those names for your environment, but you get the idea.  With the hosts identified, you can now connect the vSphere Client directly to those hosts and move forward with the real troubleshooting.


Popular posts from this blog

Deleting Orphaned (AKA Zombie) VMDK Files

Clone a Standard vSwitch from one ESXi Host to Another

vCenter Server Appliance Crash due to Full /Storage/SEAT Partition