Virtually Jason

We've been configuring a large number of ESXi servers that don't have local hard drives.  As such, we need to set up each system's scratch location on persistent storage, as per that KB article from VMware. That KB Article has a great section devoted to performing the process from PowerCLI and it basically takes you through the whole thing, soup to nuts, for a single ESXi host.  That's all well and good, but what if you've got 16 hosts?  Or 32?  Or 64?  Well, with a few minor changes to the procedure that they've outlined, you can very easily target every ESXi host in an environment.  Bear in mind that this process does require a host reboot, so make sure that you have your ducks in a row (and preferably do this before you place any VMs onto the cluster). Instead of their step 6, I used this command to create a folder for all ESX hosts in the inventory: get-vmhost | foreach {new-item ".$($_.name)/scratch" -itemtype directory} Instead of their s

Here's a quickie.  As part of this big vCenter forklift, we want to verify that all VMs are communicating on the network after they've been migrated to the destination systems.  I shudder to imagine someone typing out "ping vma" and then "ping vmb" etc. for all of these machines... and so I created this command to do the work for us!  It grabs the list of all VMs from the host esx01, then does two tests.  First, it checks to see if the vm has a hostname (from VMware tools), then it attempts to ping that hostname.  If the VM doesn't have a hostname or if that VM doesn't respond to ping, the command spits out a quick message saying that the VM failed to ping. get-vmhost *esx01* | get-vm | foreach {if(!($_.guest.hostname) -or !(Test-Connection $_.guest.hostname -count 1 -quiet)){echo "$($_.name) failed to ping"}} Quick note - this command uses the test-connection cmdlet, which was introduced in PowerShell 4.0.  You can use $psversiontable.

1/26/2016 Update:  We've learned that this script doesn't elegantly handle the situation where multiple VM folders have the same name (but different parent folders).  I've put together a basic script that should help recover from that (in the comments), but I haven't had a chance to thoroughly test it.  That script is built to move all VMs from the "Discovered Virtual Machine" Folder back into their correct locations.  I'm working on an updated pair of scripts that will handle this whole situation better. 2/9/2016 Update:  I've published an updated version of the vCenter Migration Scripts  - check it out instead of these! One of my customers wanted to export their VM Folder structure and the associated permissions from one vCenter to another, in preparation for a vCenter forklift.  Once the destination vCenter was fully prepared, the goal would be to migrate ESXi hosts with VMs into the new vCenter, then move the VMs into the appropriate folders. 

One of my customers is standing up a lot of new resources.  The Distributed vSwitch makes it really easy to configure the ESXi hosts correctly with all of the necessary VLANs, but how do you know that they're fully plumbed end to end?  The best thing that I can think of is to simply test it; stand up a VM on each Port Group and validate its network connectivity.  Of course, you've only got two or three VLANs to test, right?  Yeah, right.  This customer has a few dozen Port Groups to validate, and since I'm not interested in wearing out my mouse, I decided to script things. To accomplish this particular task, I actually wrote two scripts.  One of them is designed to run on a test VM and changes its network identity (IP Address and Default Gateway) and runs the ping test, the other runs on an administrator's workstation and changes the Port Group that the test VM is using.  After each script makes its required change, it prompts the administrator to proceed (so that you