So one of the things that did happen whilst I was away, and that does bear repeating (as it’s not marketing fluff) is the Virtualization Eco Shell Initiative and their beta release landing (Thanks Virtua-al).

The goal of the Vizioncore Virtualization EcoShell is to provide a freeware desktop application for novice and expert IT administrators leveraging Windows PowerShell scripts across their multi-platform virtual environments.  

Fostered and supported by The Virtualization EcoShell Initiative (VESI) – an online community-driven Web site sponsored by Vizioncore – the Virtualization EcoShell is enhanced by the participation of community members through the exchange of new ideas, value-add services and extendable scripts.

Slick, no? Ok, so that was a marketing quote there, but it is quite impressive, look at some of the HTML reports:

Screenshots also the thanks of Mr Al. I’ll try to get a quick demo posted in the next day or so as well.

While glancing over at PoSH today (the tiny turtle) I was inspired to do a bit of thinking and talking about using PoSH. Specifically the VI Toolkit, it really wouldn’t be blog worth otherwise would it? What I got thinking on, and what someone on irc clued me into, was storing credentials.

Why store credentials?

Well, the beauty of automation is that you don’t have to be there for it to happen. I mean really, your sprinklers go off without intervention, why shouldn’t your scripts? The conflict come is, is that Virtual Center requires authentication, and based on that authentication, you are granted some permissions and such. Storing these credentials is what makes the hands off automation happen. After all, do you really want to turn your sprinklers on each time?

Storing Credentials

This is the part of the post where we get into the code, so if you are faint of heart, or allergic to chicken teriyaki, you can move along now. Still with us? Great!

Built into the VMware VI ToolKit (for Windows) Version 1.5 are a few cmdlets that make this really really simple:

• New-VICredentialStoreItem
• Get-VICredentialStoreItem
• Remove-VICredentialStoreItem

Rather self explanatory, no? Let us glance at what they look like in use:

New-VICredentialStoreItem

New-VICredentialStoreItem -host ‘vCenter.professionalvmware.com’ -user ‘marcus’ -password ‘garvey’ -file c:\test

That is all one line, and what that basically does is create an XML file representing a credential store, with your encrypted password, like this:

<?xml version="1.0" encoding="UTF-8"?>
<viCredentials>
  <version>1.0</version>
  <passwordEntry>
    <host>vCenter.professionalvmware.com</host>
    <username>marcus</username>
    <password>omitted</password>
  </passwordEntry>
</viCredentials>

Cleared out the <password></password> area for space. It should also be noted here, that C:\ is likely not the best place to be storing these, and that they’re secured by NTFS file permissions, so use whatever security policies your organization dictates for this function (if they allow this at all). This is all well and good, how do we use them now?

Get-VICredentialStoreItem

Well, who didn’t see this cmdlet coming next? I mean 1/2 the page up I foreshadowed it quite heavily. As you can guess, using this cmdlet is not all that difficult, but we’ll show you how to use it anyways:

[VI Toolkit] C:\> $creds = Get-VICredentialStoreItem -file c:\test
[VI Toolkit] C:\> $creds | fl *

Host     : vCenter.professionalvmware.com
User     : marcus
Password : garvey
File     : c:\test

Cool, so we opened our credential store, and stored it in a variable, and as we can see that variable has a few properties to it, so lets use these to connect to a vCenter:

[VI Toolkit] C:\> connect-viserver -Server $creds.Host -User $creds.User -Password $creds.Password

Good stuff, in fact, excellent stuff. Considering, you can use this beyond storing just vCenter/ESX credentials, anything that requires a user/pass/hostname can be stored in this manner, and used again within your VI ToolKit scripts.

Now that we have all of this excellence, we’ll take a look at making it go away once your security guys catch wind of what you’ve been up to.

Remove-VICredentialStoreItem

Now, the foreshadowing and the lead in, if you couldn’t guess this title… no bacon and pancakes for you.

Looking at the get-help for Remove-VICredentialStoreItem, there are a number of ways you can remove said credential stores, you can specify the file, like we did in the past two examples, or, you can do like we do in this one, and use the pipeline:

[VI Toolkit] C:\> $creds | Remove-VICredentialStoreItem

Confirm
Are you sure you want to perform this action?
Performing operation "Remove-VICredentialStoreItem" on Target "Remove credential store item for
host ‘vCenter.professionalvmware.com’ and username ‘marcus’?".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Of course the answer is [Y]es, we want to do this, and if you want to actually turn the confirmation off, you can specify the “-confirm:$false” flag.

This of course brings us to the grand conclusion of this post. If you found this useful, please consider subscribing, and telling a friend (or three), if not, well… don’t tell anyone. If you have questions or comments, ping me on twitter, or via the comments.

From the VI Toolkit blog.

Can you spot the difference between this code:

1: foreach ($vm in (get-vm)) {

2: $disks = Get-HardDisk -vm $vm

3: foreach ($disk in $disks) {

4:  Write-Host $disk.CapacityKB

5: }

6: }

And this code:

1: foreach ($vm in (get-vm)) {

2: $disks = Get-HardDisk -vm $vm.name

3: foreach ($disk in $disks) {

4:  Write-Host $disk.CapacityKB

5: }

6: }

This is not quite a trick question, the only difference is that one uses $vm and one uses $vm.name in the second line. Both of these are valid and produce the same results. However, there’s a really important difference between them. I timed these code samples in my environment and here are the results:

    * Code sample 1 (aka Fast): 13.44 seconds.
    * Code sample 2 (aka Slow): 3178.55 seconds.

1. Try to load as many objects as possible into arrays beforehand. Once you’ve got them loaded you can use them as arguments to multiple calls without having to resort to potentially expensive lookups every time.
2. Just like in sample 1 above, when you’ve loaded objects, use the objects directly rather than using their names. This is usually not hard as our cmdlets are designed to take object first-and-foremost, and names are supported just as a convenience.
3. If you absolutely need to load a single VM object by name, load it using the Get-VMFast function below. While this approach can certainly help, it’s not nearly as good as using the other two techniques mentioned above.

What we have today, was brought up on #ESX on EfNet. They were looking for a script to generate output similar to what you get by clicking on “Hosts and Clusters”, selecting “File > Export > Export List…”

Like this:

What I came up with is not quite as pretty, but, it works, and you can schedule it using the Windows Task Scheduler. First the code:

   1:  Begin {

   2:      $hostCount= @{

   3:          Name = "hostCount"

   4:          Expression = { $_ | get-vmhost | measure-object | %{$_.Count} }

   5:      }

   6:      $vmCount = @{

   7:          Name = "vmCount"

   8:          Expression = { $_ | get-vm | measure-object | %{$_.Count}  }

   9:      }

  10:  }

  11:   

  12:  Process {

  13:      $InputTypeName = $_.GetType().Name

  14:      if ( $InputTypeName -eq "DatacenterImpl" ) {

  15:          $output = $_ | select Name, $hostCount, $vmCount

  16:          return $output

  17:      }

  18:  }

I’ve saved this in a file creatively called export-list.ps1. It requires you to be connected to a vCenter server, and accepts a datacenter object ($InputTypeName –eq “DatacenterImpl”) from the pipeline. From there it takes each, and spits them out, like this:

[VI Toolkit] C:\> get-datacenter | .\scripts\export-list.ps1

Name                                        hostCount                   vmCount

—-                                        ———                   ——-

dev                                              1                         3

stage                                            1                         5

prod                                             1                         8

Sexy, right? Not so much, but this is where PowerShell and the VI Toolkit shine, in their flexibility. So you want HTML? Check this out:

[VI Toolkit] C:\> get-datacenter | .\scripts\export-list.ps1 | ConvertTo-HTML > report.html

Just open report.html, and run with it. Scheduling this in Task manager isn’t that much harder, but will remain a task for the reader.

Maybe not ‘roids, but with a large helping of awesome, like, vDiagram, shown below. Click on over to virtu-al.net to see the rest.

If like me you couldn’t get to VMworld Europe 2009, this will be great news. They’ve made the VI Toolkit Lab available online. I’ll give this a run through later tonight.

I wasn’t there, but had a few other folks on Twitter point out to me that I got a mention during one of Carters presentations on automating VMware with PowerShell. Startled and amazed by this, I asked for some proof, and well… got it:

Woo! For those that didn’t know I’ll be doing a similar presentation, along side Pancil at the Virtualization Congress in Vegas this May.

It’s 7PM, do you know where your VMware Tools are? Rather, do you know if all your VM’s have them installed and running?

Here is a one-liner to check that with PowerShell:

get-vm | where { $_.PowerState -eq "PoweredOn" } | Get-VMGuest | where { $_.State -ne "Running" } | select vmName, State

What this does, is get a list of VM’s, selects those that are running, and then gets the tools status and selects those that do not have a status of “Running”. Easy… no?

Here’s another one-liner to check to see if you have the tools configured to sync time with the host system:

get-vm |where { ( %{ get-view $_.Id } | where { $_.Config.Tools.SyncTimeWithHost -ne "True" } ) } | select name

This one, gets a list of VM’s, then takes from that list, the VM’s that do not have tools set to sync with the host system. There is a lot of { and ( action there… because that info is pretty well hidden.

What else do you check for on your VM’s… tools versions? etc? Leave me a note in the comments.

When your network engineer, or other random folks are looking for some assistance in updating their vlan map Visio, or are generally trying to make their work yours (who doesn’t love to delegate) you can bash out this one liner against your VI, and instantly have a list of what VM is on what VLAN.

Yes the formatting sucks, and yes, in my lab I only have a single VLAN (unless someone wants to send me a smart switch), but this gets the point across:

PS C:\Users\bunchc> get-vm | %{ write-host $_.Name `t ($_ | Get-VirtualPortGroup | select vlanid)}
dc01.nerv.local      @{VLanId=0}
monitoring.nerv.local      @{VLanId=0}
rcli.nerv.local      @{VLanId=0}
This Is A Clone      @{VLanId=0}
shell.nerv.local      @{VLanId=0}
fs.nerv.local      @{VLanId=0}

For further network information, all wrapped up in a sexy csv, you can use Alan Renouf’s script here.
Questions? Thoughts? Corrections on my Caca code? Leave me a note in the comments, or hit me up on twitter @cody_bunch

Things break. They always do. Chaos is inevitable. So how do you get insight into some of the chaos that was occurring in your Virtual Center when disaster strikes? Turns out, the VI Client makes this quite easy.

After you get your Virtual Center service running again, connect using the VI Client. Once connected… well follow along:

File > Export > Export Diag Data

The resulting window:

The options you select here determine the logs you get… Be careful when doing this across your entire VI, as it may take quite some time. For our example, we’ll stick with just the Virtual Center logs. After that, select a path and hit OK! This generates a task, much like the following:

What this task does, is give you the time to go get a cup of coffee. Really (Remember the note above? Now imagine we did this across 200 hosts).  Done:

This task generates a folder in the location you specified prior. The contents of the folder file look very much like:

PS C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49> dir

Directory: C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
d—-         1/25/2009   7:07 PM            viclient-support
-a—         1/25/2009   7:09 PM   76580475 vcsupport-2009-01-25@19-07-49.zip

Contained within the sub folder are logs related to the VI Client. They look like:

PS C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49viclient-support> dir

Directory: C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49viclient-s
upport

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
-a—         1/12/2009   9:15 PM      73010 viclient-0.log
-a—         1/18/2009   9:50 AM      43329 viclient-1.log
-a—         1/18/2009  10:49 AM     295807 viclient-2.log
-a—         1/18/2009  12:22 PM      63804 viclient-3.log
-a—         1/18/2009   9:29 PM      46094 viclient-4.log
-a—         1/19/2009   8:28 AM     106489 viclient-5.log
-a—         1/20/2009   1:30 PM      63542 viclient-6.log
-a—         1/20/2009   4:03 PM        133 viclient-7.log
-a—         1/25/2009   7:07 PM     142524 viclient-8.log
-a—          1/9/2009   8:17 PM     169476 viclient-9.log
-a—         1/25/2009   1:43 PM        235 viclient-index.xml

Cool. Good to know but for the moment we’re after the Virtual Center logs, hidden in that zip file. Go ahead and extract that out, it’ll give you something like this:

PS C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49vcsupport-1-25-2009-19-
4> dir

Directory: C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49vcsupport-
1-25-2009-19-4

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
d—-         1/25/2009   7:09 PM            Config
d—-         1/25/2009   7:09 PM            DrmDumps
d—-         1/25/2009   7:08 PM            Logs
-a—         1/25/2009   7:09 PM       4003 tree-vc-support.txt
-a—         1/25/2009   7:04 PM         12 vc-support-ver.txt
-a—         1/25/2009   7:09 PM       9656 vc-support.log

Config, DMP Dumps, and Logs. Looks like we’ve found the meat of this search. In the log’s folder you’ll find a *.csv and *.evt of the event logs on the system at the time this dump as taken. More importantly tho, you’ll also find the vpxd folder… these are the logs we’re after!

PS C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49vcsupport-1-25-2009-19-
4Logsvpxd> dir

Directory: C:Documents and Settingscody.bunchDesktopVMware-VirtualCenter-support-2009-01-25@19-07-49vcsupport-
1-25-2009-19-4Logsvpxd

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
-a—         1/25/2009   7:04 PM    9437340 profiler-0.log
-a—         1/25/2009   6:05 AM  209715224 profiler-1.log
-a—         1/24/2009  11:40 AM  209715224 scoreboard-0.log
-a—         1/25/2009   7:05 PM   26585551 scoreboard-1.log
-a—         1/23/2009   7:33 AM    5242904 vpxd-0.log
-a—         1/25/2009   7:05 AM    5242904 vpxd-1.log
-a—         1/25/2009   7:04 PM    1719036 vpxd-2.log
-a—          1/9/2009   3:44 PM    5242904 vpxd-3.log
-a—         1/11/2009   1:50 PM    5242904 vpxd-4.log
-a—         1/13/2009  12:22 PM    5242904 vpxd-5.log
-a—         1/15/2009  12:35 PM    5242904 vpxd-6.log
-a—         1/17/2009  12:41 PM    5242904 vpxd-7.log
-a—         1/19/2009   8:48 AM    5242904 vpxd-8.log
-a—         1/21/2009   7:51 AM    5242904 vpxd-9.log

On these I believe they count from 0 to 9, 9 being the oldest, 0 being the most recent, but the dates on these files seem to disagree with me…

These logs, can also be grabbed using the VI Toolkit for windows like this:

PS C:> get-log –bundle

That’s it! Next time we’ll go over reading these a bit.