Virtually Jason

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 VI

One of my customers asked me to help out with the zoning configuration on their Brocade fiber switches.  I'm neither a SAN nor a network engineer, but I've created a few fiber zones in my time.  The best practice that I've always heard is to create 1:1 zones.  That means that each zone has 1 initiator (an ESXi host's VMHBA) and 1 target (the storage processor on the SAN).  This is a very simple process, but it's also really arduous and really boring, especially as environments scale up with redundant VMHBAs and multiple SANs with redundant storage processors. So, I spent a little bit of time reading about how to use the Brocade CLI , then moved forward.  I'm not quite confident enough in my scripting to actually enable any changes on the Brocade switches (after all, if you mess something up, storage could simply go away), so what I did was create a PowerCLI script that generates a bunch of Brocade CLI commands.  These commands (after you've read them over