vSphere PowerCLI

There’s been a lot of PowerCLI-related stuff going on lately that’s worth checking out.

vProfiles and more.

Monsieur Alan Renouf has been hard at work lately and had turned out some really amazing stuff. The first is what he calls vProfiles. From the looks of it, vProfiles is still in a fairly early stage, but right now it is able to duplicate virtual switch and portgroup information between two ESX hosts via a graphical interface. Alan also posted a video showing the script in action.

vProfiles from Alan Renouf on Vimeo.

This looks really exciting and Alan is looking to improve its functionality over time to include more than just networking. Chances are it’s also very easy to extend this to apply a configuration to an entire cluster rather than just a single host, and I think we’ll see that ability pop up in the near future.

Another really cool script Alan wrote recently was SnapReminder. SnapReminder will automatically generate an email nag to anyone who has left a snapshot sitting around too long. The most notable thing about SnapMinder in my opinion is that it blends together information from VMware vSphere and Active Directory in a completely seamless way. As if that weren’t enough there are some other great scripts Alan wrote between these two that are also worth checking out.

vWire.

vWire is a new product from the people who brought us Tripwire (some of us feel old when we think about the first time we used Tripwire.) Anyway, the vWire team has taken some of this knowhow and have produced a tool to monitor and analyze your VMware environment, and keep it running smoothly.

vWire has some videos that can help you get started, particularly their getting started video. vWire also offers some really powerful, SQL-based searching capabilities. You may be wondering what this has to do with PowerCLI, but vWire supports script actions, which let you run PowerCLI scripts to do things like display log files or change ESX host configuration. You can see all their content in their content library.

vWire lists for $295 per CPU + Support, and if you’ve got more than a very basic Virtual Infrastructure vWire might a great addition to your portfolio of management tools.

Lastly, but not leastly, PowerWF Studio.

I blogged about PowerWF Studio a while back on the VMware VIX blog, but since then they have also released support for PowerCLI. PowerWF Studio is a graphical workflow builder built on Windows Workflow Foundation

There are a lot of great PowerWF videos on YouTube but one of the best ones right now shows you you can take a PowerShell script you have already written and embed it in a workflow. If you’ve ever visited our communities, or read PowerCLI blogs you know that there are hundreds of really useful scripts out there that solve myriads of problems. With PowerWF it’s now easy to embed these in workflows.

As PowerWF continues to add more actions and adds the ability to talk to more and more software products it should be a tool worth watching.

Yesterday someone took the liberty of upgrading one of my ESX servers that I use to run a virtual vSphere lab. Fortunately he was kind enough to preserve all of the VMs, and they were restored and re-registered after the upgrade.

There was one detail that he didn’t notice, which was that my virtual vSphere lab VMs were all connected to an internal network called “Internal”. When I got in today my lab didn’t work at all because there was no networking between vCenter and the ESX hosts or their shared storage. The network cards all said they were attached to the “Internal” network, but there was no Internal network! Fortunately this was pretty easy to fix with PowerCLI.

First, let’s look at a script that will identify any VM that is connected to a non-existent network:

# Search for VMs that are connected to a non-existent portgroup.

$pgNames = Get-VirtualPortGroup | Foreach { $_.Name }

Get-VM | Where { $_ | Get-NetworkAdapter | Where { $pgNames -notcontains $_.NetworkName } }

This code starts by getting a list of all portgroup names. Then it goes through all VMs and identifies any VM that has at least one network adapter connected to a non-existent portgroup. Note that this assumes we are connected directly to ESX. If you need to use something like this against vCenter you should do it on a host-by-host basis. Anyway, when I ran it here was the result:

These are all the VMs of my virtual lab. Now let’s go about fixing the problem. First, creating the Internal virtual switch and portgroup are pretty easy:

# Create the missing switch and portgroup.

New-VirtualSwitch -Name Internal

Get-VirtualSwitch -Name Internal | New-VirtualPortGroup -Name Internal

Now the portgroup exists but there is one last problem: the VMs are not actually connected to the portgroup. Again, pretty easy to fix.

# The guests that were powered on will still be disconnected, so connect them.

Get-VM | Get-NetworkAdapter | Where { $_.NetworkName -eq "Internal" } |

  Set-NetworkAdapter -Connected:$true -Confirm:$false

With that, everything is back to normal.

This post is going to cover some useful and popular recent content seen on our community. If you haven’t seen our community, it really is the best way to learn about PowerCLI and start getting automated. Today I’m going to touch on two topics. First, I’ll cover a script to list all RDM information, then give a script that will let you add NFS datastores to all your hosts in one shot.

Listing RDM Information

If you’re wondering what an RDM is or why you might use it, check out Rich Brambley’s blog for a really good explanation. Long story short is that RDMs are often used because you need to use Microsoft Cluster Services, or if you want to take advantages of features of your storage hardware.

In PowerCLI, RDMs will show up when you run the Get-HardDisk cmdlet. Specifically they will have a type of either “rawPhysical” or “rawVirtual”, depending on the type of RDM. However, they won’t have things like the SCSI LUN, which you may find very useful to report on. If you need this information, Luc Dekens has the script you’re looking for. It will list all RDMs on all VMs, along with their size, SCSI device, etc.

Adding NFS Datastores to Multiple vCenter or ESX Hosts

If you have more than a few hosts you probably have shared storage, this is what enables a lot of vSphere’s great features like vMotion. For this to work smoothly, however, you need that storage to be available on all your hosts in a consistent way, and this can turn in to quite a challenge as your environment grows.

Not long ago a question was asked about how to automate adding datastores across multiple vCenters. Not surprisingly, Luc also suggested an answer, and it’s a pretty good one. However I want to offer a slightly different answer. The first thing we should do is define all our NFS mapping information in a CSV file, like this:

One great feature of PowerShell is its Import-Csv cmdlet, which will turn lines from a CSV file into objects that you can access just like any other object. My variation on Luc’s solution is to use the Group-Object cmdlet and group these entries by the VCName property. This way, if you’re adding multiple datastores to a single VC, you only have to log in once. Here’s my full solution to the problem, which assumes that you’ve saved your data into a file called nfs.csv.

Import-Csv nfs.csv | Group VCName | Foreach {

 Connect-VIServer -Server $_.Name

 Foreach ($entry in $_.Group) {

  Get-VMHost | New-Datastore -Nfs -Name $entry.DatastoreName `

   -Path $entry.NfsExport -NfsHost $entry.NfsHost

 }

}

Closing Thought

Be sure to check out our community, it really is the most valuable source of information for automating with PowerCLI.

Last year at VMworld I gave a talk about PowerCLI (back then it was VI Toolkit for Windows) which was attended by about 650 people. No eggs were thrown so I have to guess it was an ok session. Eric Siebert agreed and recommended that it be made freely available. Well, now it is, and you can view the session using your VMworld account.

The session has a high-level overview of PowerCLI, samples and a couple of pretty cool demos courtesy of my colleague Andrey Anastasov and Mr. PowerGUI, Dmitry Sotnikov of Quest Software. If you’re hoping to get your vSphere environment more automated, it’s worth checking out.

In case you missed our June 2009 PowerCLI webinar, a replay is available. In this webinar I covered some tips for getting stats out of vSphere, viewing log data and advanced configuration.

I’ve made all the scripts used in this presentation available for download. Bonus: There is also a sample in there that shows scheduling a nightly report.

You can also see the presentation on slideshare.

Other important links mentioned in the webinar were:

• VI Toolkit Extensions
• VESI (A graphical frontend to PowerCLI)

Enjoy

As I announced a few weeks ago, I’ll be giving a webinar on Wednesday, June 3 2009 to cover the most popular PowerCLI topics as determined on our voting site.

The topics I’ll cover are:

1. Analyzing log data.
2. Reporting.
3. Advanced ESX host configuration.
4. Performance analysis.
5. A brief mention of the tools for provisioning ESXi.

Be sure to mark your calendars!

If you’re looking at upgrading to vSphere, one thing that may come in handy is an easy and flexible way to move custom fields from your old vCenter to your new one. With PowerCLI this is quite easy… except for one thing: there is no Get-CustomField cmdlet! The why is a long story but it turns out it’s pretty easy to write just such a thing. In fact here it is:

function Get-CustomField {

 param($item)

 foreach ($cf in $item.CustomFields) {

  if ($cf.Value) {

   $field = "" | Select Key, Value, EntityName

   $field.Key  = $cf.Key

   $field.Value  = $cf.Value

   $field.EntityName = $item.Name

   Write-Output $field

  }

 }

}

Not too hard at all, really. So how do we use this? One nice feature of PowerCLI that often gets overlooked is its ability to connect to multiple vCenters at once and manage them all. We can take advantage of this to connect to both our old vCenter and our new one, and move the values directly between them. The way this works is to store the output of Connect-VIServer in a variable, then pass this variable to later cmdlets to specify the server you want to manage. For example:

$server1 = Connect-VIServer vcserver1

$server2 = Connect-VIServer vcserver2

This next bit of code will take all custom fields on all VMs in vcserver1 and transfer them to vcserver2. This assumes the VMs already exist in both locations.

$fields = Get-VM -server $server1 | Foreach { Get-CustomField $_ }

$vms = Get-VM -server $server2

foreach ($field in $fields) {

 $vm = $vms | Where { $_.Name -eq $field.EntityName }

 Set-CustomField -Entity $vm -Name $field.Key -Value $field.Value

}

That’s really all there is to it. If you need to transfer custom fields on more than just VMs, say maybe you also have fields on ESX hosts, you can use a more general bit of code that will do this for all types of objects. I’ve added that example to my script repository and you can download it here.

As you’ve probably seen by now,VMware vSphere was launched late last night and people all over the world are busily downloading it. If you want full details on the release the best place to find it is this excellent blog post by Eric Siebert.

At the same time, we’ve also released PowerCLI 4.0, which is the successor to VI Toolkit 1.5.

The mathematically astute amongst you may have noticed that the version number jumped from VI Toolkit 1.5 all the way to PowerCLI 4.0. Does that mean there were huge changes between 1.5 and 4.0? Not really. The numbering was changed to be in line with the version of vSphere that is released on the same day. In the past there had been a lot of confusion around what version numbers were needed, especially since ESX 3.0 was released at the same time as VirtualCenter 2.0, and later ESX 3.5 was paired with VirtualCenter 2.5. To simplify things, many of our products have begun to use the same version number, 4.0. This will also be true going forward.

Does that mean that PowerCLI 4.0 only works with vSphere 4.0? Not at all, in fact you can use PowerCLI to manage ESX and VC all the way back to 3.0 and 2.0, respectively (see how confusing that is?) Best of all, the code you wrote for managing ESX 3.0 or 3.5 will most likely work on vSphere with no modification, and you can use it to manage and automate a mixed environment of all these versions.

So what is actually new? It’s easier to describe if I share a bit of backstory. Originally there was not going to be a VI Toolkit 1.5, all of the planning we did assumed these features would be shipped with vSphere. Because PowerCLI finished development well before vSphere was ready, we decided to remove a few vSphere-specific features and release the rest of them as VI Toolkit 1.5. We kept the PowerCLI release in reserve, waiting for the big day. In the meantime we’ve been hard at work on our next feat of engineering wonder, PowerCLI 4.0 U1, which will arrive later this year.

To put it another way,

PowerCLI 4.0 = VI Toolkit 1.5 + Bug Fixes + Host Profile Cmdlets

Host profiles is a nice new feature added in vSphere that helps in large-scale provisioning and configuration auditing of ESX servers. Yavor Boychev from the PowerCLI team even put together a nice video that explains when, why and how to use the feature.

Managing host profiles with vSpherePowerCLI! from Yavor Boychev.

If you’re looking to get started right away, Hugo has a terrific Quick Start Guide on his blog.

As always, the best part about PowerCLI is our strong community, which continues to grow stronger every day. Hope to see you there.

Steven Murawski and Scott Herold will be talking PowerShell and PowerCLI tomorrow at the Wisconsin VMware Users Group and it should be quite an interesting talk. You can find all the details on Steven’s blog. A recording will also be available after the fact just in case you’re not able to make it.

We did two live demos as part of VI Toolkit’s breakout session at VMworld Europe 2009. A while ago, I made a post about the network monitoring demo. As LucD politely reminded me : ) it’s time to finish the job with a post on the second demo. In it, PowerShell scripts were sending mouse and button clicks to a virtual machine’s guest OS to automate installer which otherwise does not support unattended installation...

Every once in a while I find myself in a situation where I can save tons of work with a very simple UI automation. In this specific case, I’m upgrading the VMware Tools on my VMs. The Update-Tools cmdlet is the right tool for the job. There’s a small problem in my case though...

The new version of VMware Tools I’m installing is still a beta and hasn’t passed Microsoft’s driver quality tests. So when Update-Tools runs the installer, Windows pops “unsigned driver” confirmation dialog and blocks the installation. In result, Update-Tools blocks on the first VM. That’s where UI automation comes into play. I need a script which goes inside the VM’s guest OS and clicks on the confirmation button.

Windows Automation Snapin for PowerShell (or WASP) is a set of cmdlets for UI interaction. UI interaction includes stuff like finding windows and controls and sending them mouse clicks, keyboard input, etc. Sounds like the right tool for my task. I’ll need to run it not on my machine but inside each individual VM. VI Toolkit’s cmdlet for in-guest execution is Invoke-VMScript.

Finally, below is the script. Two notes:

-       You need to be connected before you run it.

-       For simplicity’s sake (this was a VMworld demo), the script only operates on a single machine. Extending it to work on a set of VMs is pretty straightforward.