vSphere PowerCLI Blog

One nice new addition to ESX 4 is the ability to manage the complete routing table through the API, something that you had to do through the service console in previous releases.

So, how does PowerCLI help with automating all of this? Well, not much, really, PowerCLI doesn’t have any cmdlets related to routing. But this wouldn’t be a very interesting blog post if that was the end of the story. The nice thing about PowerCLI is that it gives you full access to VMware’s extremely powerful platform, which makes it easy to fill in any missing pieces we haven’t gotten to yet.

We have such a thing in the form of the VI Toolkit Community Extensions. One of the recent additions to the extensions is a set of commands that give you total control over ESX routing, and in a way that is compatible with all of PowerCLI’s cmdlets.

The new functions are as follows:

Get-TkeVMHostRoute

New-TkeVMHostRoute

Remove-TkeVMHostRoute

This stuff will look familiar to anyone who has used our cmdlets. If you’ve used our cmdlets before, chances are these will work the way you expect them to without a great deal of additional learning. Once you load the extensions you can run help on any of these function names and get a listing of the options they support.

Below is a quick run-down on how this stuff works. The first and easiest thing to do is to see what routes you have. I have an ESX 4 host with an IP address of 192.168.1.11. The key thing to note is that Get-TkeVMHostRoute requires a VMHost argument, and also allows you to pipe it in. To get a listing of its routes I run:

Get-VMHost 192.168.1.11 | Get-TkeVMHostRoute

Here’s some sample output:

With ESX 4 there are 3 types of routes, host routes which apply to the host, console routes, which apply to the service console (you won’t have these if you use ESXi) and the routing table. Above you can see that I have a host route and 3 entries in my routing table, and that my default route is 192.168.1.1.

Let’s see what adding and removing routing table entries looks like. Let’s suppose I can use 192.168.1.254 to reach the 10.24.0.0/16 network. Here’s how to do it:

Get-VMHost 192.168.1.11 |

 New-TkeVMHostRoute -TableRoute -Network 10.24.0.0 -PrefixLength 16 `

 -Gateway 192.168.1.254

Pretty simple, really. Here are the results of that.

New-TkeVMHostRoute can handle all 3 types of routes. Run help New-TkeVMHostRoute to learn more about it.

To remove routes from the routing table, all you do is pipe a route into Remove-TkeVMHostRoute, like this:

Get-VMHost 192.168.1.11 | Get-TkeVMHostRoute |

 Where { $_.Network -eq "10.24.0.0" } | Remove-TkeVMHostRoute

Something that’s not immediately obvious is how you change the host or service console route, since there’s no Set-TkeVMHostRoute. In truth there should be a Set-TkeVMHostRoute and probably will be one at some point. But for now this can be done using New-TkeVMHostRoute, which will just override any existing settings.

Changing your service console IP is similar, except you will also need to specify your GatewayDevice. If you have multiple service console IPs you can set each of them by specifying different gateway devices.

If this stuff looks useful to you, be sure to check out the VI Toolkit Extensions for this and a lot more great stuff. You should keep in mind that the extensions require PowerShell v2 CTP3, which is still in technical preview mode. But if that’s something you can use anyway you’ll find it to be extremely helpful.

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:

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!

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:

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.