But which HW versions can you use in your environment? 

It seems there is no enumeration available listing all the valid HW versions. But we can use the a REST API call to query the vCenter.

$vcName = 'vcsa.fqdn'
$hwService = 'com.vmware.vcenter.vm.hardware'

try{
    Connect-CisServer -Server $vcName -ErrorAction Stop
}
catch{
    throw "Connection to the $vcName vSphere Automation SDK server failed."
}


$hw = Get-CisService | where{$_.Name -eq $hwService}
$validHWVersion = $hw.Help.upgrade.version.Element.CreateExample().Split(':')[1].TrimEnd('.').Replace(' ','').Split(',')

Disconnect-CisServer -Server $vcName -Confirm:$false

In the array $validHWVersion you will now have the permitted HW versions for your environment.

On a side note, use the HardwareVersion parameter on the Set-VM cmdlet to configure the HW version for a VM. The Version parameter is deprecated.

Get-VM -Name MyVM | Set-VM -HardwareVersion vmx-17

The following script shows you can automate this for 1 or more VMs.

$data = @'
vCenter,VM
vcsa1,vm1
vcsa2,vm2
'@

$dumpLocation = 'C:\MemeoryDumps'
$dumpItem = Get-Item -Path $dumpLocation

ConvertFrom-Csv -InputObject $data -UseCulture -PipelineVariable row |
ForEach-Object -Process {
    Connect-VIServer -Server $row.vCenter

    $vm = Get-VM -Name $row.VM
    $snap = New-Snapshot -VM $vm -Name "Memory dump" -Memory -Confirm:$false
    if($snap){
        $vm.ExtensionData.UpdateViewData('Layout.Snapshot')
        $snapObj = $vm.ExtensionData.LayoutEx.Snapshot | where{$_.Key -eq $snap.Id}
        if($snapObj){
            Get-Item -Path "$dumpLocation\$($row.VM)" | Remove-Item -Recurse -Confirm:$false
            $tgtDir = New-Item -Path $dumpLocation -Name "$($row.VM)" -ItemType Directory
            $files = @()
            $files += $vm.ExtensionData.LayoutEx.File | where{$_.Key -eq $snapObj.MemoryKey} | select -ExpandProperty Name
            $files += $vm.ExtensionData.LayoutEx.File | where{$_.Key -eq $snapObj.DataKey} | select -ExpandProperty Name
            $files | ForEach-Object -Process {
                $dsName,$filePath = $_.Split(' ')
                $ds = Get-Datastore -Name $dsName.Trim('[]')
                New-PSDrive -Location $ds -Name DS -PSProvider VimDatastore -Root "\" | Out-Null
                Copy-DatastoreItem -Item "DS:$filePath" -Destination $tgtDir -Confirm:$false
                Remove-PSDrive -Name DS -Confirm:$false 
            }
        }
        else{
            Write-Output "Failed to retrieve snapshot info for $($row.VM)"
        }
        Remove-Snapshot -Snapshot $snap -Confirm:$false | Out-Null
    }
    else{
        Write-Output "Snapshot failed for $($row.VM)"
    }

    Disconnect-VIServer -Server $row.vCenter -Confirm:$false
}

The script uses a here-string and the ConvertFrom-Csv cmdlet to get the names of the vCenters and the VMs, but you can easily change this to any source for providing the information.

The issue is that all values on ArgumentList are passed as one array to the code block of the Start-Job cmdlet. The trick is to to present your array as one value to the background job. This can be done through the array notation with (,$myArray).

An example

$job = {
    param(
        [PSObject[]]$Array
    )

    $Array | ForEach-Object -Process {
        $_
    }
}

$arrP = 1..4 | ForEach-Object -Process {
    New-Object -TypeName PSObject -Property @{
        Field1 = $_
        Field2 = $_ * 2
    }
}

Start-Job -ScriptBlock $job -ArgumentList (,$arrP) |
Wait-Job | Receive-Job -Keep

If you need to pass multiple arguments, you can add these on the ArgumentList parameter. Like this.

$job = {
    param(
        [string]$String1,
        [PSObject[]]$Array,
        [string]$String2
    )

    $String1
    $String2
    $Array | ForEach-Object -Process {
        $_
    }
}

$arrP = 1..4 | ForEach-Object -Process {
    New-Object -TypeName PSObject -Property @{
        Field1 = $_
        Field2 = $_ * 2
    }
}

Start-Job -ScriptBlock $job -ArgumentList 'Test1',(,$arrP),'Test2' |
Wait-Job | Receive-Job -Keep

This also works when you need to pass multiple arrays to the background job.

$job = {
    param(
        [string]$String1,
        [PSObject[]]$Array1,
        [string]$String2,
        [PSObject[]]$Array2,
        [string]$String3
    )

    $String1
    $Array1 | %{$_}
    $String2
    $Array2 | %{$_}
    $String3
}

$arr1 = 1..4 | ForEach-Object -Process {
    New-Object -TypeName PSObject -Property @{
        Field1 = $_
        Field2 = $_ * 2
    }
}
$arr2 = 1..2| ForEach-Object -Process {
    New-Object -TypeName PSObject -Property @{
        Field3 = $_
        Field4 = $_ * 3
    }
}

Start-Job -ScriptBlock $job -ArgumentList 'Test1',(,$arr1),'Test2',(,$arr2),'Test3' |
Wait-Job | Receive-Job -Keep

Due to the way PowerCLI is written, it is not possible to use the VimInventory and VimDatastore providers, that come with PowerCLI, from the PowerShell Integrated Console.

Note that this is the console that shows the following.

You will see the following error when you try to set up a drive with one of these providers.

This is a known problem and mentioned in PowerShell/PowerShellEditorServices Issue #543 and also in the VMTN thread Microsoft Visual Studio Code (VS Code) can not access vi and vis, vmstore and vmstores. Get-PSDrive and New-PSDrive -PSProvider VimDatastore dont work as expected

A couple of workarounds are available:

• Disable the PSScriptAnalyzer in VSC
• Don’t hover over PowerCLI cmdlets in the editor.
• Load the PowerCLI modules before hovering over a PowerCLI cmdlet in the editor

Of course, the preferred solution is option 3 from that list. And since VSC has it’s own profile, it is quite easy to implement.

Create/modify the VSC PowerShell profile, with

notepad $profile

In the profile file, add the following line

Import-Module -Name VMware.PowerCLI 6> $null

The redirection of stream 6 is intended to suppress the Write-Host output from loading the VMware.PowerCLI module. This will only work in PowerShell v5, and higher.

If you find the output produced by loading the VMware.PowerCLI module annoying, there is a PowerCLI Idea that asks to suppress this “feature”. Please upvote the issue if you also would like to see this removed.

The following might seem a bit cryptic at first, but it turns out to be the fastest method I came up with till now.

It uses the where-method instead of the Where-Object cmdlet. See also Use the ‘faster’ methods.

$mac = '12:34:56:78:90:12'
$sView = @{
    ViewType = 'VirtualMachine'
    Property = 'Name','Config.Hardware.Device'
}
(Get-View @sView).Where{$_.Config.Hardware.Device.Where{$_ -is [VMware.Vim.VirtualEthernetCard] -and $_.MacAddress.Equals($mac)}} |
Select-Object Name

If you need to look for a number of MAC addresses, you can do

$macs = '12:34:56:78:90:12','12:34:56:78:90:34','12:34:56:78:90:56'

$sView = @{
    ViewType = 'VirtualMachine'
    Property = 'Name','Config.Hardware.Device'
}
(Get-View @sView).Where{$_.Config.Hardware.Device.Where{$_ -is [VMware.Vim.VirtualEthernetCard] -and $macs -contains $_.MacAddress}} |
Select-Object Name

When you want to run PowerCLI code in the background, there are a number of conditions to take care of.

• Your existing connection to a vSphere Server (vCenter or ESXi) is not inherited by the background job. You will have to establish the connection in the background job. With the SessionId parameter, you can reuse an existing connection.
• A background job shouldn’t rely on any interactivity. For that reason you want to disable all warning messages any of the PowerCLI cmdlets might generate
• A background job normally has no access to the variables defined in the calling code. You can pass values through the ArgumentList parameter on the Start-Job cmdlet.
• You do not need to include any Import-Module cmdlets in your background job., when
  • you are using a PowerShell version (v3 and above) that supports the module autoloading feature
  • you have the PowerCLI modules installed in one of the folders listed in $env:PSMOdulePath,
  • you haven’t used the $PSModuleAutoLoadingPreference variable to change the default behaviour

The following is a minimal example of such a background job. It will call the Get-VM cmdlet for a specific VM’s name.

$code = {
    param(
        [string]$Server,
        [string]$SessionId,
        [string]$VMName
    )

    Set-PowerCLIConfiguration -DisplayDeprecationWarnings $false -Confirm:$false | Out-Null
    Connect-VIServer -Server $Server -Session $SessionId
    Get-VM -Name $VMName
}

$vmName = 'TestVM'
$sJOb = @{
    ScriptBlock = $code
    ArgumentList = $global:DefaultVIServer.Name, $global:DefaultVIServer.SessionId, $vmName
}
Start-Job @sJob

Once a job is started in the background, you can wait for its completion and ‘receive’ the output. For example like this.

$j = Start-Job @sJob

Receive-Job -Job $j -Wait

Get acquainted with all the Job related cmdlet to use background jobs at their fullest potential.

But there are some caveats you should be aware off. Most of these are how the variable substitution will work when you call the ExpandString method.

• For variables you don’t want to be substituted, you need to escape the dollar sign with a back-tick. Note that this is also true for the Booleans $true and $false.

$data = @'
$var1 = $val1
$var2 = $true
'@

$val1 = 1

$ExecutionContext.InvokeCommand.ExpandString($data)

$data = @'
$var1 = '$str1' 
'@

$str1 = 'A string'

$ExecutionContext.InvokeCommand.ExpandString($data)

• When referencing properties from an object, use the correct notation.

$data = @'
`$var1 = '$($obj.Field1)\Temp' 
'@

$obj = New-Object PSObject -Property @{
    Field1 = 'C:'
}

$ExecutionContext.InvokeCommand.ExpandString($data)

The basic rule is quite simple, if you display less than 5 properties, the PowerShell output engine will display the results as a table.

Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB

Results in

When there are 5 or more properties, the output will be displayed as a list.

Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB,UsedSpaceGB

Another rule worth knowing, is that the first Select-Object output determines how the other Select-Object outputs in your script will be displayed.

The 1st one shows 5 properties, so it will be displayed as a list. But also the 2nd one, which only displays 3 properties, will also be displayed as a list.

Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB,UsedSpaceGB
Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB

When you do the reverse, you will notice that the output is in table format, but the 5th property will not be shown.

Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB
Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB,UsedSpaceGB

One way to avoid that the 1st Select-Object determines how the others in your script behave, is to use the Out-Default cmdlet.
This cmdlet kind of “resets” the output, and so the 5-properties rules will be applied as if it was the first Select-Object.

Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB | Out-Default
Get-VM -Name TS? | Select Name,PowerState,NumCpu,MemoryGB,UsedSpaceGB

$cmd = @'
vmkping -c 5 $ip
'@

$ipTargets = '192.168.1.1','192.168.1.2'

$session = New-SSHSession -ComputerName $esx.Name -Credential $cred –AcceptKey

foreach($ip in $ipTargets){
    $cmdSub = $ExecutionContext.InvokeCommand.ExpandString($cmd) 
    $result = Invoke-SSHCommand -SSHSession $session -Command $cmdSub 
}

Remove-SSHSession -SSHSession $session | Out-Null 

Note that we have single quotes on the here string, so there will be no variable substitution.

In the foreach loop we populate the $ip variable with the different target IPs. Then we force variable substitution with the ExpandString method.

In case you have your data in an object, you will have to use the normal conventions for variable substitution in a string.

$cmd = @'
vmkping -c 5 $($obj.ip)
'@

$ipTargets = (New-Object PSObject -Property @{IP = '192.168.1.1'}),
            (New-Object PSObject -Property @{IP = '192.168.1.2'})

$session = New-SSHSession -ComputerName $esx.Name -Credential $cred –AcceptKey

foreach($obj in $ipTargets){
    $cmdSub = $ExecutionContext.InvokeCommand.ExpandString($cmd) 
    $result = Invoke-SSHCommand -SSHSession $session -Command $cmdSub 
}

Remove-SSHSession -SSHSession $session | Out-Null 

With the arrival of the Posh-SSH module, there is no more need to use any of the PuTTY EXE.

Running a command on an ESXi node, provided SSH is running, is now as simple as:

$session = New-SSHSession -ComputerName $esx.Name -Credential $cred –AcceptKey

$result = Invoke-SSHCommand -SSHSession $session -Command $cmdSub 

Remove-SSHSession -SSHSession $session | Out-Null