Thanks to none other than Mr. Luc Dekens the VI Toolkit Community Extensions are growing by leaps and bounds.
Here's a full list of the new advanced functions Luc has added:
||Show all privileges defined by VirtualCenter.
||Gets Cisco CDP info for a given host.
This lets you know what switch port your host is on.
||Lists permissions assigned to a given object.
||Show all privileges defined by a role.
||Gets all roles defined in VirtualCenter
For example, Administrator, Read-Only, etc.
||Create a new role in VirtualCenter.
||Remove permissions from an entity.
||Remove a role from the system.
||Set an entity's permissions.
||Change the definition of a role.
As you can see most of these are around roles and permissions. Armed with these cmdlets you have a pretty complete way to automate the setup of permissions.
The other cmdlet is Get-TkeCDPInfo. CDP stands for Cisco Discovery Protocol, and if your ESX host is connected to a switch port that supports CDP, this cmdlet will help you determine what switch port the system is actually connected to.
Also, the VI Toolkit Community Extensions have been updated to support the newly-release PowerShell CTP3. One of the big differences between CTP2 and CTP3 is that script cmdlets are no longer supported, instead they have been replaced by Advanced Functions. Advanced Functions have a number of advantages over script cmdlets, one of the most obvious is support for embedding documentation in the function. If you load the community extensions and type "help Get-TkeCDPInfo" you'll get a full usage listing as well as other help to get you started. All in all, this stuff is starting to get a lot more usable.
If you can't wait to get started, be sure you have CTP3 installed and download the Community Extensions today!
Great work, Luc!
Hal posted a thread the other day about an apparent bug in New-VM which manifested itself by the inability to use all of the guest operating system types the documentation says are valid.
It turns out that the VI API Reference lists every possible guest OS that has ever been supported by any VMware product, and that a majority of them are invalid for any given version of ESX.
So which ones can you actually use? The answer is there, hidden under the usual web service layer that people so often resort to when cmdlets aren't quite enough. I suggested that a cmdlet to list the actual supported systems was in order, and in fact LucD created just such a cmdlet and added it to the VI Toolkit Community Extensions.
Here's a picture of it in action:
While we all eagerly await CTP3 of PowerShell Version 2 I wanted to mention that I'm a big fan of PowerShell Version 2's modules and script cmdlets because combining these technologies makes it possible to build large, cohesive and really useful management modules even if you're not a developer.
Glenn Sizemore has written just such a script cmdlet that lets you set the security properties of virtual switches. With his cmdlet you can configure whether virtual switches allow virtual machines on the switch to see traffic to and from other virtual machines using the -AllowPromiscuous flag. With the -ForgedTransmits flag you can configure whether VMs are allowed to send packets using a different source MAC address from the VM's real MAC address, and with the -MacChanges flag set, VMs on the switch can change their MAC addresses.
These options can be useful for enabling security-related applications, for instance if you want to run an intrusion detection virtual appliance on a virtual switch you'll need to set -AllowPromiscuous on the switch. The default is to have AllowPromiscuous disabled while ForgedTransmits and MacChanges are enabled, which is pretty much what you get with a real unmanaged switch.
Glenn's cmdlet makes changing things really easy. You can see Glenn's original cmdlet, but note that the name and parameters are changed a bit in the community extensions, to make it fit a bit more with other aspects of the extensions. Here's a quick example of the new cmdlets in action:
||# List all my virtual switches and their security properties.
||Get-VMHost | Get-TkeVSwitchSecurity
||# Enable Promiscuous Mode on vSwitch1 on all ESX hosts in cluster SQL
||Get-Cluster SQL | Get-VMHost | Set-TkeVSwitchSecurity vswitch1 -AllowPromiscuous
The VI Toolkit Extensions is now up to 30cmdlets that cover a wide range of really useful stuff. If you're looking to get started with the VI Toolkit Community Extensions, Eric Sloof has a great writeup on how to do just that. As PowerShell v2 nears official release, we've got some things planned to make the VI Toolkit Extensions amazingly easy to use, for now it's a bit primitive but gets the job done.
The guys over at Quest have been working hard and have made a massive update to their PowerGUI PowerPack for VMware management. Whether you're a PowerShell expert or just starting out, PowerGUI is a great way to manage VMware because not only does it provide a simple, point-and-click way to manage your ESX servers, but PowerGUI also generates real, usable PowerShell code as you click. This code generation feature will have you automating in no time, even if you're not a PowerShell expert.
Kirk Munro notes that there's a whole slew of new features, some of my favorites include:
- Seamless management of multiple ESX or vCenter (formerly known as Virtual Center) hosts.
- Enhanced navigation of the VMware inventory that will be very familiar to people who use the VI Client.
- Lots of new object types and actions.
- The ability to browse files on datastores.
You can get started by downloading PowerGUI over at PowerGUI.org. Also be sure to read Kirk's announcement over at Poshoholic, Kirk's blog has 100% more snowfall than this blog does.
Congratulations to Kirk and the rest of the PowerGUI team!
Eric Siebert has published his list of the Top 10 PowerShell scripts that VMware administrators should use, this is really useful stuff for people who are trying to automate and report on their virtual infrastructure.
Also, be sure to check out Eric's blog for lots of other really helpful VMware tips and information.
The VI Toolkit for Windows provides 125 cmdlets, which is a pretty big number. However, ESX and vCenter are big and complex products, so 125 cmdlets is nowhere near comprehensive. Our challenge is to grow the toolkit to be a complete automation solution while not confusing the heck out of everyone with a giant list of commands.
One of the ways we've approached the problem is to provide a cmdlet called Get-View which gives you access to the raw web services API provided by ESX and vCenter. When something is not provided natively through cmdlets, you can use the Get-View "escape hatch" to do just about anything you want. Today's theme is just that, a few recent examples from the community that show how you can do some really useful stuff, even though we haven't yet written a cmdlet designed to do it.
Templates can be quite big and pose a challenge to storage management, so it's nice to be able to move them around. Moving templates across datastores is something the VI Toolkit doesn't do out of the box, but not to worry, Niket shows how you can move templates across datastores by accessing the VI API.
Even though the VI Toolkit doesn't have a cmdlet for it, Hal shows that it's pretty easy to reboot or shut down an ESX host with PowerShell.
If you need to add an unregistered VM to ESX or VC, Luc shows how you can register a VM based on its VMX file. One of these days we'll be adding an Add-VM cmdlet that will make this really easy, but this is a workable solution in the meantime.
With the Toolkit it's really easy to get a listing of all disks associated with a VM, however it doesn't help you identify what disk it is within the VM itself. This week, a couple of solutions have been proposed, one from adavidm and one from Hugo Peeters. Both these scripts rely on a combination of some of the advanced data available through VI API and also getting information out of a Windows VM via WMI
BTW, if you haven't subscribed to Hugo's blog you should really do so, it's full of great tips.