Michael asked if it was possible to produce a report that showed the NX/XD flag setting for all the guests.
Piece of cake I thought, but it turned out to be a bit more complex than that. If you don’t set the NX/XD flag (expose or hide) explicitly on the guest, the hyper-visor will use a default that is defined per OS you can have on the guest.
In the end I think I came up with a script that seems to handle all the different possibilities I encountered.
Today Steve Jin published a post called How to Enable ESX Server Logs for Troubleshooting. A very useful tip when you are looking for those hard-to-find “features” in your script.
Steve’s tip reminded me that I have a similar small function in my toolchest to do something similar for the vCenter log.
The function allows you to switch the vCenter log between “warning” and “verbose” on the fly. No need to go into the vCenter client to change the logging option anymore while debugging.
Triggered by a recent post, see get-virtualportgroup, in the PowerCLI Community, I had a closer look at the Get-VirtualPortgroup cmdlet.
This cmdlet returns a VMware.VimAutomation.Types.Host.VirtualPortGroup object, which contains a very useful property called Ports. In that property it lists all the guests that are connected to a port on the portgroup. That would be the solution to find unused portgroups, I thought. But while the vSphere Client also shows powered off guests that are connected, the Port property returned by the Get-VirtualPortgroup cmdlet doesn’t. 🙁
So the question at hand required a bit more scripting than I originally thought.
When you are running multi-node vSphere clusters, you probably already had the experience that one or more of your LUNs were not visible on all nodes. Now you can try to find out which LUN is missing on which node the hard way through the vSphere client. Or you can use the force of PowerCLI and run a script that will report all this in a handy spreadsheet.
To make the script as flexible as possible it should be able to handle any n-node cluster. And as you some of you might know, the Export-CSV cmdlet has some problems with variable length rows. Luckily there is a handy solution I already used in my yadr – A vDisk reporter post.
Continue reading LUN report – datastore, RDM and node visibility
After my yadr – A vdisk reporter post I received an email from Dennis Zimmer, known from VMachine blog and as the IcomaSoft CTO. He pointed me to the yUML website and suggested that I could perhaps use part of the yadr script to produce an UML diagram.
As it happended there were already some PowerShell scripts that used the functionality offered by the yUML website to produce UML diagrams. Have a look for example at Use PowerShell and yUML to Create Diagrams by Doug Finke and Create Database Diagrams with Powershell + yUML by Chad Miller.
As you probably guessed by now I was sold to the idea.
I know there are already numerous scripts to report on virtual hard disks and most of them without a doubt much better then what I came up with for this post.
The reason I started with this script was a question in the PowerCLI Community from Alan in his Thin Provisioned Disks post. He wanted to know if you could get the provisioned and the allocated disk size for a thin provisioned virtual disk.
Today there was quite a bit of activity on Twitter following Jason Boche‘s blog post titled VMware Update Manager Becomes Self-Aware.
The problem Jason discovered was that the VUM skipped the guests which are hosting the VUM server and the vCenter server. As a consequence you can not select a cluster, select “remediate” and go out for lunch anymore. The resolution was a rather cumbersome and error prone manual procedure.
But of course PowerCLI can help the human vSphere administrator 😉
One of the feature requests that came up in several emails I received for my dvSwitch series, was how to get and set the network adapters of virtual guests. In the current PowerCLI version the Get-NetworkAdapter and Set-NetworkAdapter cmdlets can not handle portgroups on dvSwitches.
That is why I created the following two functions, called Get-dvSwNetworkAdapter and Set-dvSwNetworkAdapter.
Continue reading dvSwitch scripting – Part 8 – Get and Set network adapters
You should know by now that alarms are a powerful tool to help you manage and monitor your vSphere environment. But in my opinion there is a basic operation missing.
There is no easy way to move an alarms from one entity to another entity. No drag-and-drop in the vSphere Client, no Move-Alarm cmdlet in PowerCLI.
A practical example, you have developed this fantastic new alarm and for testing purposes you had defined it on a single virtual machine. Now the tests are done and your alarm is ready for production. But there is apparently no easy way to move your new alarm to the root of your vSphere environment.
A couple of weeks ago Charu Chaubal published his draft vSphere 4.0 Security Hardening Guides in the Security & vShield Zones community. If you haven’t read them yet, you definitely have to put them on your To-do list.
A vSphere administrator often considers security as a necessary evil that he has to take care of at a point in time, preferably a few days before an audit is going to take place 😉
Charu’s Guides can make this exercise a lot easier. And if we add to those guides some scripts to automate the hardening process, the vSphere administrator has no more excuses to tackle security on a regular basis (like it should be !).
