Another interesting question in the PowerCLI Community today.
David wanted to know if it was possible to track which VMs had been failed over to another ESXi host by HA.
With the Get-VIEventPlus function from my Get the vMotion/svMotion history post it is easy to get that informatiom from the Tasks and Events that are kept in the vCenter database.
But which event to look for ?
When you need to move the content of one or more datastores, you sometimes stumble upon files that you didn’t know where there. One such type of files are dump files that are stored in a VM’s directory on the datastore.
The files I encountered were named like this:
There isn’t a lot of information available on what exactly these files are used for, besides that they seem to be created when the VM Monitor encounters a crash or a serious problem.
Since these files were quite old, and since I didn’t have any open tickets with VMware, I decided to remove these files. But of course in the PowerCLI way with a function 
The availability of vMotion and svMotion, provided you have a license that allows it, in vSphere are some of its key features.
The DRS and SDRS functionality will use vMotion and svMotion to better use the available resources.
And you as a vSphere administrator can use it to facilitate your work. Just think of how easy patching or datastorecluster maintenance becomes with the help of these two features.
But as an administrator you want to be able to report on what vMotion and svMotion have been doing over a specific time interval in your vSphere environment.
In the past I already provided a vMotion reporting tool in Events – Part 8 – vMotion history, but now it was time to provide a universal (s)vMotion reporting feature.
Another post triggered by a question in the VMTN PowerCLI community. The user wanted to know how he could create a report that showed for which vSphere entities the alarm actions were disabled.
To set the stage, a short overview of what this is all about. In vSphere you can, since vSphere 4, disable and enable alarm actions for all the managed entities. This option is available from the vSphere client
and from the vSphere Web client.
But how to automate these actions, and more importantly in this case, how to report on the active settings ? Like always PowerCLI to the rescue.
I had the pleasure to present a session on “PowerCLI and vSPhere Performance and Capacity reporting” during the Dutch VMUG meeting of February 8th 2013. Although the meeting took place in the “Karnaval” weekend, there was a great turnout and, as always, a very attentive and interested audience. Thanks for attending the session guys !
In the session I tried to show how easy it is to produce decent performance and capacity reports about your vSphere environment with PowerCLI. During the session I did some demos to show some aspects of PowerCLI and statistics. This post contains the code, and some annotations, I used during these demos.
One of the exciting new dvSwitch features in vSphere 5.1 is the ability to export and restore a dvSwitch configuration. This new feature is only available through the vSphere Web Client.
On Hypervisor.fr, a blog you should have in your RSS reader, there were already posts on how to configure the dvSwitch healthcheck and how to do a dvSwitch configuration rollback from PowerCLI. But till now, as far as I know, there were no functions to provide the dvSwitch export/restore functionality.
Time to make this useful functionality available for the “PowerCLI automation crowd”
One of the hot new features in vSphere 5 was the introduction of SDRS. And with SDRS came the concept of affinity rules for VMs and VMDKs. Cormac, aka @VMwareStorage, posted a nice overview of the SDRS affinity rules in Storage DRS Affinity & Anti-Affinity Rules.
Since then several posts have appeared on the subject of SDRS affinity rules. To list just a few:
Currently there are no PowerCLI cmdlets to define the inter- and intra-vm anti-affinity rules for SDRS. After a question in the VMTN PowerCLI Community I decided to write a function. This function will allow you to automate the creation of the SDRS anti-affinity rules.
Another post that comes from a VMTN PowerCLI Community question. Jeff wanted to find the free SCSI LUNs in his environment.
While answering that thread I was amazed there was no PowerCLI function written yet to provide this functionality. At least that was what my friend Google told me
Since there exists a SDK method that makes retrieving free SCSI LUNs quite easy, the function I came up with isn’t too complex.
But it should help you in further automating the setup of your datastores.
Some time ago I published the Export-Xls function to the world in my Beyond Export-Csv: Export-Xls post. And it has been one of the more popular functions on my blog.
Just before Christmas 2012 I got a comment from Gilbert where he informed me that he had written an Export-Xlsx function and had borrowed some of the parameters that were on the original Export-Xls function. We exchanged a couple of emails with suggestions and ideas, and yesterday the finalised Export-Xlsx function was posted on Gilbert’s ITPilgrims blog (which you should follow btw) in his Export-Xlsx post.
In this post I will publish this new Export-Xlsx function with some annotations, and I will also show how you can now export your data in the order you want, provided you’re using PowerShell v3.
The end of the year is near again. Time to plan for the new, but also a time to look back on what was there in the past year.
Your vSphere environment is no different. It is time to produce some of those dreaded year reports that will show you how your environment has been doing. And one of the aspects a lot of people are very keen about, is the number 9 game
What was the uptime of the VMs you had running ?
The question popped up on several occasions in the PowerCLI Community as well. So I guess I was not the only one that was looking for a way to calculate the uptime of Virtual Machines.
Bug alert ?: it seems that the PerformanceManager handles vMotions in a strange way. After a vMotion the sys.uptime.latest is reset to 0 (zero). That is understandable, since the VM is now running on a different ESXi host. But it seems that the aggregated metric do not add up all the sys.uptime.latest metrics from different ESXi hosts. So when you use DRS or do vMotions yourself, the produced report will have some serious flaws !
