It’s been a while since I updated so I thought I’d mention a few videos I made a while back that give some useful tips in using PowerCLI 4.0 U1.
Video 1: Using multiple sessions with PowerCLI 4.0 U1.
This first video shows a few tips for dealing with multiple sessions with U1. With U1 you can connect to multiple vCenters or multiple ESXes or even some vCenter and some ESXes and apply your commands across everything. There’s a lot of possible uses here but Glenn Sizemore pointed out an interesting use where if his vCenter ever goes offline he’s not sure where it is (Glenn probably uses DRS and vCenter can move around somewhat randomly.) With this new feature he can just log in to all his ESX hosts at once and find it.
It’s also worth pointing out that U1 has a bug that if you use SSO to log into vCenter, then disconnect, you won’t be able to log back in using SSO without restarting PowerCLI. Expect this to be fixed in the next release.
Video 2: Importing vApps with PowerCLI 4.0 U1.
Importing OVF-based vApps with PowerCLI is pretty much a one-liner. It’s about as easy as it gets, what more can you say?
Video 3: New Invoke-VMScript Goodies.
The Invoke-VMScript cmdlet runs a script inside your guest and returns its output. Two major improvements to Invoke-VMScript were made in U1, first you can run BAT scripts instead of PowerShell scripts within your guest. Second, Invoke-VMScript now supports shell scripts on Linux. Perfect for the occasional Linux sysadmin.
Video 4: NIC Teaming Policies.
If you were trying to dream up the 7 deadly sins of virtualization, not having redundant networking would probably be number 1. Think of it this way, you’re putting 5 or 10 or 20 virtual machines into one physical box, then relying on a flimsy little cable to connect all of this stuff to the outside world. If you’re going to put all your eggs in one basket, you have to make sure it’s a really good basket. So everyone who virtualizes needs redundant networking, and this video shows how you can set up, configure and also audit your virtual network settings.
Video 5: Patching ESX 4.
We also added the ability to patch ESX 4.0 and up in U1. It also supports a number of different patching mechanisms, such as web-based, datastore based, and local file based. This video shows what I would consider to be the best practice for patching a bunch of ESX hosts, namely upload the patch to some datastore all the hosts can see and then issue the patch commands as in the video. If you take this approach patching is a lot faster since you’re not uploading the patch multiple times.
If you’re the sort of person who reads fine print, you’ll notice that this cmdlet is marked as experimental in the documentation. Sometimes people call things experimental just because they’re afraid people will use it and they won’t be able to whimsically change it to whatever they feel like. In this instance however, and for reasons I can’t really elaborate on too much, there is a very good possibility this interface will be forced to change in the future. So I would say use it against ESX 4 if you find it useful, but don’t depend on it working the same way when ESX 5 (or whatever it ends up being called) is shipped.
