Virtually Jason

Earlier, I published a quick note about basically using SSH from one ESXi host to manipulate settings across all ESXi hosts in the environment.  I've realized that it might be helpful if I include this note, around how I easily turn SSH on or off across an arbitrary number of ESXi hosts in the environment. This script is super basic - run it after connecting your powerCLI session to whatever vCenter servers you're interested in.  Then, pass it the "-h" option and a regular expression that matches the hosts that you want it to manipulate (such as *esx1* or a specific hostname or even just *).  That's it; it'll turn on the SSH service on all of those hosts, which should open the required firewall ports automatically and everything will just work. Turning SSH off again when you're done is just as simple.  Use the command the same way, but with the "-o" switch... and now the script will sweep through, turning SSH off for all hosts that match ...

As a quick followup to my note around the Full netGP Heap Issue , we've found ourselves in need of a way to easily monitor the netGP status across many hosts in the environment while we await the patch that fixes the issue.  I've searched high and low for a way to access vsish or the netGP Heap stats from PowerCLI but haven't had any luck.  So, I've put together a quick and dirty solution... but it gets the job done. All that I've done here is put together a quick PowerCLI script that generates a Shell Script (just redirect the output to a file).  That Shell Script can then be executed from one of your ESXi servers (ensure that SSH is enabled!) in order to pull information from all of the servers in your environment. $AllHosts = Get-VMHost foreach ($ThisHost in $AllHosts) { write-output "echo Host $ThisHost" write-output "ssh $ThisHost 'vsish -e cat /system/heaps/netGPHeap-0x4100013cc000/stats' | grep 'percent free of max si...

As part of the ESXi vCenter Migration  that I performed recently, we had to convert the ESXi hosts back to Standard vSwitches (from the Distributed vSwitch).  The built-in Wizards make the transition from Standard to Distributed nice and easy, but I don't know of any such path for easily moving the other direction.  We determined that we'd manually create the Standard vSwitch with all of the port groups from the Distributed vSwitch... but there were about 20 port groups that needed to be transitioned for each of the hosts in the cluster.  Aside from the arduous labor involved in that process, I was concerned about typos that might be introduced by depending on manual labor to accomplish that process.  So, I wrote a quick PowerCLI script to take care of it. This script takes 3 arguments; Host, Source and Destination.  The Host is the ESXi Host on which the operation should be performed.  The Source is the Distributed vSwitch that should be copied (thi...

One of my customers was transitioning into a cloud service provider, and as such their ESXi infrastructure needed to be changed around to support this decision.  A fairly standard design element of a provider datacenter is to break up the environment into 2 vCenter environments; one for management elements and one for customer VMs.  As such, we stood up the second vCenter server... but then we had the challenge of how do we move the exiting customers into the new customer resource vCenter? It wasn't that hard, although it took a little planning to ensure that we didn't cause any service disruption to the VMs that were already running.  Adding to the complexity of the move was the fact that Distributed vSwitches were in use at this site.  Given that vCenter owns the Distributed vSwitch, we weren't sure how the system would behave if we simply took over ownership of the ESXi servers into the new vCenter, so we settled on the following procedure: Remove vShield com...

(8/10/2015)  Update:  Unfortunately, some backend things have changed since I originally cobbled this script together and it doesn't work any more.  I'll fix it if I get the chance, but in the meantime, there's a free utility called  RVTools  that can identify orphaned VMDK files (which are entertainingly called Zombie VMDKs on the vHealth tab of the application).  That's a great application to be aware of anyway, as it makes it very easy to get access to a lot of important information that the vSphere client obscures. (11/9/2015) Update: I went ahead and put together a post detailing how I used RVTools and a helper script to identify, rename and then delete orphaned VMDK files . Every organization has to wrestle with orphaned VMDK files.  What is an orphaned VMDK file, you ask?  It's a VMDK file that's sitting on your SAN, consuming expensive storage, but isn't actually being used by any VM.  They're notoriously hard to find (especially...

A few customers have been hit by an intermittent issue where virtual machines seem to reject their network adapters.  In Windows, this shows up as the guest OS reporting a hardware failure on the NIC (which, given that the NIC is virtual, is bit of a hard sell).  So, while the VM has a network adapter attached to it and it is connected to the network, the VM doesn’t get any network access.  If you open up device manager, the “general tab” for the network adapter will show an error (error 10 if memory serves).  When you try to update the driver on the NIC, it will fail to install it.  I’ve only ever seen this with the vmxnet3 adapter, but I’ve heard that it can affect e1000 as well. Typically, the VM’s network connectivity can be restored by some combination of removing the vNIC from the VM and adding it back (well, it’s technically a new one as it will have a new MAC address), reinstalling the VMTools and/or removing nonpresent NICs from the guest OS.  T...

Here's another quick one.  A customer of mine recently had to change their NTP settings across every ESXi host in their environment.  Given that they have a lot of clusters with different storage and network settings, host profiles didn't seem to be the best solution available.  Fortunately, PowerCLI has a few nice easy cmdlets to make life easier.  After a bit of quality time on google and the PowerCLI Cmdlet Reference Page , I was able to put together the following quick script.  It goes through every ESXi host in the environment, removes all configured NTP servers, adds whatever servers are specified in the $NTPServers array, sets the service to "on" (this site had some inconsistent configurations there) and restarts the service to ensure that the settings take effect. If you want to make use of any of this, just change the variables near the top to be a list of your NTP Servers of choice.  If you want to limit the scope of the script, you can change t...