Critics are raving about Hal Rottenberg’s new TrainSignal video “The Case of the Open Snapshot”, a taut psychological thriller that will send your emotions on a roller coaster ride as our sysadmin hero fights bravely to save his datastore, keep his servers up and avert an international crisis. Ok maybe I made some of that up but this still pretty useful information.
Hal shows how to:
Report on snapshots, including snapshot size and age.
Delete snapshot en-masse, including snapshots that are so big they can take hours to remove.
Recently someone asked me if there was a way, programmatically, to figure out the “observed IP ranges” and “observed VLANs’” that you can see in vSphere Client. Don’t know what I mean? Here’s a picture to help you out.
The data is available as a tooltip in the network configuration tab (naturally!) when you hover over Observed IP Ranges. How do you get this stuff out of the API.
Turns out there’s a rather obscure little function called QueryNetworkHint. This function takes the name of the physical NIC as input, which makes it perfect for pairing with our Get-VMHostNetworkAdapter cmdlet. Here’s a PowerShell advanced function that does exactly that, followed by some screenshots of it in action.
Let’s have a look at that in action. First some basic usage, combining Get-VMHost, Get-VMHostNetworkAdapter and the Get-ObservedIPRange advanced function.
Comparing these to the screenshot above you’ll see they’re the same. Let’s take it a step further and suppose we want to determine if a certain adapter can see a certain VLAN, let’s say 2903. Here’s some code that does it:
This function can really help you out if you use sophisticated networking to your ESX hosts but don’t control the switches directly, so you have to coordinate with a member of the networking team.
Update 1: As a reader kindly pointed out, this will only show VLANs for which the ESX server has seen actual traffic, it will not probe the switch for configuration.
Update 2: The code sample has been updated to fix the type name in the advanced function. The old function used a type name that only worked in internal builds of PowerCLI.
vSphere Pro Series Volume 1 doesn’t just cover PowerCLI, in fact it covers:
Cisco Nexus 1000v
And of course PowerCLI.
For you PowerCLI fans out there here’s what to expect in Hal’s PowerCLI training:
Introduction to PowerCLI
PowerCLI Concepts – Parts 1 and 2
PowerCLI in the Real World
PowerCLI Cmdlet Deep Dives
We’re finding that the admins who know PowerCLI really well are the rock stars of their team because through their script-writing kung fu they save their team mates tons of time and can easily come up with solutions to most any crisis. These videos will put you directly on the path to PowerCLI mastery.
As a big bonus, those of you who were paying attention at VMworld 2009 will also remember that VMware View is soon going to introduce its own set of PowerShell functionality, so if you’re a View expert there’s no better way to get ready for the new power and flexibility you’re soon going to have.
If you’re at VMware Partner Exchange next week be sure to come see me at my session, TEXIBP1007 – also known as “Getting Stoned with ‘Project Onyx’” on Thursday at 11:30.
If you haven’t seen it, Onyx is a tool that converts vSphere Client UI clicks into executable code, which means that instead of writing your code the hard way you just use a tool you know and love to automatically generate your code. If you can’t wait to get started you can download Onyx or visit our community.
Since it’s Partner Exchange, for one day only I’ll be wearing my developer’s hat and showing how Onyx can help you more quickly and effectively write Java code for managing vSphere.
Top 3 reasons to attend:
Learn how Onyx can help you even if you’re a Java/C# developer and not a PowerCLI user.
Using Onyx means no more digging around in the vSphere API docs to figure out what properties you need.
Learn how Onyx can even help you debug your own applications!
Hope to see you there, it will be a fun and informative time!
In case you missed it, VMware is running a Script-O-Mania contest to find the world’s very best ESXi management scripts. One point that might be worth clarifying, it doesn’t have to manage just ESXi, so if it works with ESX and ESXi that’s ok. So dust off those old PowerCLI and get submitting!
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.