ForwardOrReverse

Steve Jin recently posted How to Notify All the Active vSphere Users on his DoubleCloud blog. Below are some functions to make this easy to do via PowerCLI.

Function Get-VIServiceMessage {
    $sessionManager = Get-View SessionManager
    $sessionManager.Message
}
 
Function Set-VIServiceMessage {
    param (
        [String]$message = $(throw "Must specify a message.")
    )
 
    $sessionManager = Get-View SessionManager
    $sessionManager.UpdateServiceMessage($message)
}
 
Function Remove-VIServiceMessage {
    Set-ServiceMessage("")
}

Here is some simple code to generate a reference list of the PowerCLI cmdlet objects(nouns) and what actions(verbs) you can perform on them.

This can come in handy for people new to PowerCLI to show them what the cmdlets will handle for them.

$commandTable = @{}
$commandList = Get-Command -Module VMware.VimAutomation.Core -CommandType Cmdlet
 
foreach ($command in $commandList) {
 
    if (!$commandTable.ContainsKey($command.Noun)) {
        $commandTable[$command.Noun] = @()
    }
 
    $commandTable[$command.Noun] += $command.Verb
}
 
foreach ($command in $commandTable.Keys | Sort-Object) {
    $verbs = $commandTable[$command] | Sort-Object
    $command | Select-Object @{Name="Noun"; Expression={$command}}, 
                                 @{Name="Verbs"; Expression={[String]::Join(",", $verbs)}}
}

Here is the output for PowerCLI version 4 update 1.
Read more…

Here is an script to make life a little easier when doing bulk updates to a password for an account as long as the account has a common password on the different hosts.

Read more…

I have been experimenting with parameter values from the pipeline and the processing behavior is slightly different when using piplines vs. parameterized values. It is easy enough to work around, but I wanted to make sure and explain the issue and one workaround.
Read more…

Update Manager 4.0 Update 1 was refusing to install either of these two patches. At first I was confused because I did not have Nexus deployed, but this was looking similar to the problem that Update 1 was supposed to fix.

I downloaded the bundle from VMware’s web site and tried to install the patch manually and got this error:

The following problems were encountered trying to resolve dependencies:
   cross_emulex-cim-provider_400.2.0.27.1-164009 provides 'emulex-cim-provider
   >= 400.2.0.27.1' (required by rpm_vmware-esx-cim_4.0.0-1.11.236512@i386), but
   is obsoleted by the host

The culprit is the HBAnywhere installation I loaded for HBA firmware management. I uninstalled HBAnywhere and the patches worked just fine.

$ sudo rpm -qa | grep elx
elxvmwarecorekit-esx40-4.0a44-1
$ sudo rpm -e elxvmwarecorekit-esx40-4.0a44-1

I originally had to follow this Emulex KB article to get the application installed.

I went to Emulex’s web site to find a HBAnywhere update package for ESX 4 U1 and now I can not find a download for the original version let alone an updated one. The firmware update manual still lists HBAnywhere as a utility for VMware though.

If anyone knows of an updated package or another way to do firmware updates online I would appreciate letting me know in the comments.

UPDATE 5/6/2010
The current version of HBAnywhere resolves this issue. Here are the newest downloads for VMware.

Here is some PowerShell code to determine the VMs that are in a VMware Site Recovery Manager recovery plan.
Read more…

A reference for those working on Google book searches other than full text queries. Let me know if something is incorrect or missing.

Here are the possible values for the policy parameter on Set-VMHostService and their corresponding value in the VI client.

A lot of the script that I have been writing rely on new cmdlets or properties in the current release of PowerCLI. Telling people to upgrade before running the scripts has not been enough so I am going to do the smart thing and check that the appropriate version is running.

Here is the code to that I am using to do the validation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# By default this will check that the running version of PowerCLI is greater
# than or equal to the specified version and throw an exception if not.
# For an exact match specify the -exact parameter.
function Require-PowerCliVersion
{
    param
    (
        [Int32]$build = $(throw "Require-PowerCliVersion: No build number specified."),
        [switch]$exact # If true requires the exact build number to match.
    )
 
    $passed = $false
 
    if (Get-Command Get-PowerCliVersion -ErrorAction SilentlyContinue)
    {
        $cliBuild = (Get-PowerCliVersion).Build
 
        if ($exact)
        {
            if ($build -eq $cliBuild)
            {
                $passed = $true
            }
        }
        elseif ($cliBuild -ge $build)
        {
            $passed = $true
        }
    }
 
    if (!$passed)
    {
        throw "Require-PowerCliVersion: Minimum PowerCLI version requirement not met."
    }
}