One user has suggested we rename the VI Toolkit forum the "Ask Luc Forum", referring to Luc Deken’s continuous help and support to other toolkit users. Here’s a few recent highlights from the forum, with Luc making quite a few appearances.
A previous post on this blog shows how to modify VMX file settings, but some VMX file setting can’t be changed in this way. Changing a VM’s boot delay is a good example. If you need to configure VM boot settings, Luc shows a way this can be done, using an API specifically designed for VM boot settings.
If you’re accustomed to logging into ESX and using the esxcfg-mpath command, but are looking for something that works at the VirtualCenter level, across all your ESX hosts, Hal has some code that makes it really easy to make storage path reports across all your ESX server.
Hugo shows how you can use the -expand switch of PowerShell’s Select-Object cmdlet to easily display a VM’s available and used disk space (assuming the VM is running VMware Tools).
If you have VMs with multiple adapters that are members of multiple port groups, Luc has some tips that make it really easy to report on which VMs are connected to which port groups.
Finally, if you’re writing reports and want the results emailed to you, Luc shows an easy PowerShell script to generate email.
If you’re like me, and I know I am, you spend an hour or two a day reading through RSS feeds. In fact, I found out about this really cool new script from Hal Rottenberg through my RSS reader, courtesy of Alan Renouf, even though Hal emailed me to tell me about it (I get so much mail from Hal I usually just ignore it.)
The beauty of RSS (in case you’ve been living under a technological rock for the past few years) is that everything comes to you, rather than the other way around. How many times a day do you really want to log into your VI to figure out what’s going on anyway? In VI you can get email notifications, but this is only for alarms, in addition to being a bad idea in general. If you look through Hal’s feed you can see that this tells you about everything, including things like an ominous warning from VMware Update Manager that it only has about 500 megabytes of space left. Just add it to your RSS aggregator of choice and suddenly you know everything that’s going on with your VI with minimal effort.
Hal hasn’t made his script public, it seems he’s using it as a teaser for his upcoming book. Let’s hope he hurries up, so drop him a note and tell him to stop goofing off all the time.
I often call snapshots "the silent datastore killer". When you create a snapshot, the system records the difference between the current state and the state when the snapshot was made in something called a delta file. The delta file can grow to be as big as the base disk itself if you write a lot of data to it. If you create a snapshot of that snapshot, the process begins again, and that snapshot can also grow to be as big as the base disk.
I’ve personally filled up many a drive with snapshots that I’ve forgotten about. When your datastores fill up, any VM trying to expand files on that datastore (for example if it has snapshots it is trying to grow) will freeze until some space becomes available. It’s a real disaster and I’ve even heard of people going so far as to disable snapshots entirely.
The trouble is that VI Client doesn’t give you an easy way to figure out how big snapshots are. Even if it did, do you really want to sift through dozens or hundreds of VMs on a regular basis looking for big snapshots manually? We need automation to solve this problem.
A new cmdlet in the VI Toolkit Extensions can help. Get-TkeSnapshotExtended adds a property called SizeMB to snapshot objects. To use it, load the VI Toolkit Extensions (in PowerShell v2 CTP2 or higher) and run
Get-VM | Get-TkeSnapshotExtended | Select Name, VM, SizeMB
Here’s some sample output:
Hope that helps!