Home > Blogs > VMware PowerCLI Blog > Monthly Archives: July 2008

Monthly Archives: July 2008

Run PowerGUI directly in VI Client!

As Dmitry announced on his blog, you can now run PowerGUI directly inside the VI Client! This is true for both the PowerGUI console as well as the PowerGUI Script Editor.

Shot0_2In other words, you can now launch the PowerGUI Script Editor, with all of the syntax highlighting, tab completion and debugging features you love without having to bother with a separate login.

The same is also true for the updated VMware PowerGUI PowerPack, which has a lot of nice features such as the ability to easily identify old snapshots.

Shot1

As if that weren’t enough, PowerGUI automatically generates reusable PowerShell code based on your actions, much like recording a macro in Excel.

Shot2

For those of you out there who have been meaning to get in to scripting this is your perfect chance to get started.

It should be noted that you need to connect to VirtualCenter for the plugin to appear. In addition you’ll need the latest version of PowerGUI and the 1.0 GA VI Toolkit.

Manage VMware Update Manager with PowerShell.

Eric Sloof has been quite busy over the past week, first figuring out how to download the VI Toolkit 1.0 before its official release (which we on the VI Toolkit team take as a high compliment), and now announcing that yes, we have added PowerShell support to VMware Update Manager via the VMware Update Manager PowerShell library.

The VMware Update Manager PowerShell snapin adds 13 cmdlets that let you download updates, set baselines, remediate and more.

As Eric points out, the snapin is distributed within the VMware Update Manager package, but can be installed separately on any system with the VI Toolkit (for Windows) installed. (We’re looking to streamline this process in the future, by the way.)

Like I said before, there’s lots more exciting news coming this week, so stay tuned.

It’s finally official, 1.0 is out!

Download the new version of the toolkit, version 1.0! You can also read the release notes if you’re in to that sort of thing.

One thing Beta users should be aware of in 1.0 is that get-viserver has been replaced by connect-viserver. This is a little bit annoying, but we needed to do it because we also needed a disconnect-viserver. If you start the toolkit from the VI Toolkit (for Windows) shortcut, you’ll find that get-viserver is an alias to connect-viserver, but it’s a good idea to migrate your code over at some point.

Anyway, enough of that boring stuff, enjoy the toolkit and stay tuned for some really exciting stuff next week.

The absolute best book on managing VMware with PowerShell you will read this year.

If you’ve been living under a rock for the past year or so, you’re probably very familiar with PowerShell and already knew that Hal Rottenberg is writing the seminal literary masterpiece on managing VMware with PowerShell. If you’ve been enjoying fresh air and sunshine instead, you should know that SAPIEN Press is offering $100 and a free copy to all qualified reviewers. Check out Hal’s blog for all the details.

Update: Hal has got all the reviewers he needs.

PowerShell scripting contest! Win $5000!

PowerShell doesn’t impress the ladies (believe me, I’ve tried) but now it can help you win $5,000, or a trip to VMworld 2008! Read all about it on the contest announcement page and good luck!

Storage path load balancing.

Rob Mokkink posted a storage path load balancing script to the VI Toolkit (for Windows) VMware Community. Rob’s script is somewhat specific to his environment, it assumes that each host has 2 host bus adapters, but it would be pretty simple to adjust it for variable numbers. The greatest thing about it is that this is the sort of feature that you would usually expect to pay big $$$ for (or big €€€ for, as the case may be), but it’s done with just barely over 100 lines of PowerShell. Way to go Rob!

P.S. Did you know that if you connect to a VirtualCenter that is using Active Directory, the VI Toolkit for Windows will automatically log in with your credentials? This is an alternative to caching credentials manually as Rob is using in his sample.

Exploring your objects.

The VI Toolkit (for Windows) focuses on making VMware management easy and automatable. One thing you’ll notice if you use the toolkit for a while is that the objects you get from cmdlets like Get-VMhost, Get-VM, etc. don’t have all the properties that are available through the VI Client. This is because in the Toolkit, we use what we call "Automation Objects", which are simplified representations of the full object model. For various reasons, the automation objects may not have the data you need. In this case, using the Get-View cmdlet, you can load the full representation (or "View") that has all of the objects data in it.

As Eric Sloof blogged a while back, there are a lot of interesting properties hiding behind the automation objects, and shows how to get at them. If you’re interested in learning more about what’s behind your objects, I’ve got a script, Get-ViewProperties.ps1 that can help. When you start the VI Toolkit (for Windows) you can either "dot source" this function in, or just copy and paste it into your window. Then, when you pass a view to Get-ViewProperties, all of its properties are printed to the console. This is a great way of exploring your objects and can help you create some really powerful reports.

Here are some screenshots of the script in action. As always, first we log in and this time I’ll load a host object for us to examine (click on the image for a better look):

Shot1_2

Let’s pass this variable to the script:

Shot2_2

That’s over 150 properties, quite a lot of stuff hiding in there!

Let’s try the same with a VM:

Shot3_2

Shot4_2

Again, that’s quite a lot of properties.

In case you’ve never seen it, you can get a hold of the same data using something called the managed object browser (or MOB), by navigating to https://<yourserver>/mob. The MOB can be a bit of a challenge to navigate at times, and the nice thing about this approach is that all nested data is presented at once. The advantage of using the MOB, however is that you can transition from one managed object to the other (say, from VM Host to VM), which this script doesn’t do.

Again, there’s a lot of good stuff in here that can serve as a great foundation for reporting. If you find anything really good, let us know about it, on the blog or on the forum.

Managing storage paths with PowerShell.

With the VI Toolkit (for Windows) we try to make easy-to-use cmdlets that any administrator with PowerShell knowledge can pick up and start managing and automating VMware almost right away. All of this takes time to develop, of course. But one of the nicest features of the toolkit is that you have complete access to the extremely powerful (if sometimes baffling) set of web service APIs, which means that you don’t have to wait for us to develop easy-to-use cmdlets in order to automate the things that matter most to you.

One request I’ve been hearing a lot lately is that people would like to automate configuration of storage paths. This tends to be most useful if you have lots of ESX hosts and lots of big expensive arrays to hold their VMs, but one aspect of storage path configuration can be very useful even if you don’t have a huge deployment. Hopefully this post will give you a few ideas of what’s possible.

Configuring storage paths through the web services in PowerShell turns out to be pretty easy, but before we talk about that I want to show how you do it in the VI Client. The first thing to do in the VI Client is navigate to a host and select the Configuration tab, then select the storage section.

Client1_3

Once you’ve done that, select a datastore and click Properties… This brings up a window like this one:

Client2_2

Now we click Manage Paths… to actually configure the paths.

Client3

Within this interface we can configure individual paths or set the path policy.

Now let’s see how to do the same thing in PowerShell. First, let’s log in. 

Command1

With native cmdlets it’s easy to manage more than one host at a time, because it’s usually completely transparent. With the web services interfaces, it’s generally best to deal with one host at a time. In the next window I load my host in preparation for configuring it.

Command2

Next I load my host’s StorageSystem. This is the object that contains all data relevant to LUNs and paths, and allows me to change their configurations. The first thing to do is to see what LUNs are available and what paths they have. Here’s how to do it:

Command3

As in my screenshots from the VI Client, I’m going to focus on my vmhba2:1:1 LUN, which has 2 paths, vmhba2:1:1 and vmhba2:2:1. Let’s set this LUN to use the experimental round-robin policy.

Command4

Let’s make sure the call worked:

Client4_2

Again, these ideas are just to get you thinking about what’s possible. Configuring a single HBA in this way is not very interesting since it’s pretty easy to do it in the client. Let’s suppose you wanted to set the round-robin policy on every LUN that had multiple paths. Here’s a script to do it:

# This script block sets any LUN with more than one path to the round-robin policy.
# Handle with care, this could easily cause you major problems!
$policy = new-object VMware.Vim.HostMultipathInfoLogicalUnitPolicy
$policy.policy = "rr"
$storageSystem.StorageDeviceInfo.MultipathInfo.lun |
  where { $_.Path.length -gt 1 } |
  foreach { $storageSystem.SetMultipathLunPolicy($_.ID, $policy) }

If experimental status sounds intimidating to you, it’s easy to set another policy, such as the fixed policy. This example sets my vmhba2:1:1 LUN to a fixed policy, with vmhba2:2:1 as the preferred path (refer to Step 3 above to see the list of valid paths.)

# Set vmhba2:1:1 to the fixed policy, with vmhba2:2:1 the preferred path.
# Note that the fixed policy type uses its own type of policy object.
$lunId = "vmhba2:1:1"
$policy = new-object VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
$policy.policy = "fixed"
$policy.prefer = "vmhba2:2:1"
$storageSystem.SetMultipathLunPolicy($lunId, $policy)

There are many, many more possibilities here. If you want to learn more about them, you basically have two choices, first you can wait until we get these sorts of things into our cmdlet set (note that this is not scheduled for our first GA release) or you can get acquainted with our HostStorageSystem interfaces and start configuring your host’s storage today.

As always, download the VI Toolkit (for Windows) to get started today.

Managing VMware with PowerShell featured on RunAs Radio.

For those who may not know, RunAs Radio is a great online Audio Talk Show hosted by Richard Campbell and Greg Hughes, and focused on Windows administration. Recently at TechEd, Hal Rottenberg managed to get us both an interview with them. That interview is now posted as their episode "Using PowerShell with VMware". Check it out, and don’t forget that Hal is soon to be an internationally famous and critically acclaimed author of a book called "Managing VMware with Windows PowerShell". Hurry up with that book already, Hal!