Finding the answer to that question is not too difficult, once you know which property holds the value. But while writing and testing the script, I thought that this question would be a good opportunity to show several ways and methods that you have at your disposal in PowerCLI and PowerShell, to come to a solution.

Here it goes.

With a bit of (logical) thinking and the help of the Get-Member cmdlet, it didn’t take long to discover where the dvSwitch port information is hiding.

As a matter of fact the port information is kept with the VirtualMachine itself, under the virtual devices, in the NIC backing object, which is called VirtualEthernetCardDistributedVirtualPortBackingInfo.

A quick-and-dirty script to get the ports could look like this.

foreach($vm in Get-VM){
  $vm.NetworkAdapters | Select @{N="VM";E={$vm.Name}},
  @{N="NIC";E={$_.Name}},
  @{N="PG";E={$_.NetworkName}},
  @{N="Port";E={$_.ExtensionData.Backing.Port.PortKey}}
}

Line 2: The script loops through all NIC that are defined on a VM

The result will appear on screen and will look something like this.

Notice that for NICs that are connected to standard portgroups, the Port property is left empty.

To get the results into a CSV file, you will have to store the results temporarily in a variable, and then, after the ForEach loop, you can pipe this variable to the Export-Csv cmdlet.

$report = foreach($vm in Get-VM){
  $vm.NetworkAdapters | Select @{N="VM";E={$vm.Name}},
  @{N="NIC";E={$_.Name}},
  @{N="PG";E={$_.NetworkName}},
  @{N="Port";E={$_.ExtensionData.Backing.Port.PortKey}}
}

$report | Export-Csv "C:\report.csv" -NoTypeInformation -UseCulture

When you visited the PowerCLI Community recently, you might have noticed that there is a poll going on about ‘regular’ and ‘fast’ solutions. A ‘regular’ solution would be one that uses the PowerCLI cmdlets to retrieve PowerCLI objects and a ‘fast’ solution is one that uses the Get-View cmdlet to retrieve (read-only copies of) vSphere objects.

In bigger environments the difference in execution time between regular and fast solutions might be substantial.

So how would we tackle the problem at hand with a ‘fast’ solution ?

$Nics = "VirtualE1000","VirtualE1000e","VirtualPCNet32","VirtualVmxnet","VirtualVmxnet2","VirtualVmxnet3"

foreach($vm in (Get-View -ViewType VirtualMachine -Property Name,Network,Config.Hardware.Device)){
  $pgs = @{}
  Get-View $vm.Network | %{
    if($_.Key){$key = $_.Key}else{$key=$_.MoRef.Value}
    $pgs.Add($key,$_.Name)
  }

  $vm.Config.Hardware.Device | where {$Nics -contains $_.GetType().Name} |
  Select @{N="VM";E={$vm.Name}},
    @{N="NIC";E={$_.DeviceInfo.Label}},
    @{N="PG";E={
      if($_.Backing.Port){$key=$_.Backing.Port.PortgroupKey}else{$key=$_.Backing.Network.Value}
      $pgs[$key]}},
    @{N="Port";E={$_.Backing.Port.PortKey}}
}

Line 1: To select the NIC devices, out of all other devices connected to the VM, the script will check if the Type of the Device is present in this array. This array contains the typenames of all possible NIC types.

Line 3: The script retrieves all the VMs. In the Property parameter the script tells the engine to only fetch those specific properties. This will cause a time saving in the execution time.

Line 4-8: The NIC device object does not have a property with the actual name of the portgroup to which it is connected. There is a property that has a ‘key’ for the portgroups. To avoid having to scan the connected portgroups each time to find the name, the script sets up a hash table.

Line 10: This line will loop through all devices connected to the VM and will only pass the NIC devices to the Select-Object in the following line.

Line 14: The key that points to the portgroup (see above) is stored in a different property, depending if the portgroup is a regular or a distributed portgroup.

Line 15: The portgroupname is retrieved from the hash table.

This ‘fast’ version of the script looks, and is, more complex than the basic function we showed before. The reason for that is that the script will have to do everything, like finding the portgroupname, by itself. In the basic function, which uses PowerCLI objects, a lot of that work is done by the logic behind the PowerCLI cmdlet.

It makes you appreciate the work the PowerCLI Dev Team put in the development of the PowerCLI cmdlets, even more.

The output of this script looks of course exactly the same (besides the order in which the VM object are returned).

If we want to report on these port numbers regularly, it is better to write a function around the logic we have from the scripts above. A function will allow us to call the functionality, just like we would call any other cmdlet.

Let’s create the function in such a way that we can retrieve the port information in 2 ways.

• Retrieve the port information for one or more VMs (similar to the functions above)
• Retrieve the port information for all VMs connected to specific Portgroups

By using parameter sets it is quite easy to package both methods in 1 function. Something like this

function Get-dvVmPort{
<#
.SYNOPSIS  Get the dvSwitch port for a VM network adapter
.DESCRIPTION The function will retrieve the dvSwitch port
  for all network adapters, provided the network adapters
  are connected to a dvSwitch.
.NOTES  Author:  Luc Dekens
.PARAMETER VM
  Specify the virtual machine(s) for whose network adapters
  you want to retrieve the port numbers.
.PARAMETER PortGroup
  Specify the portgroup(s) for which you want to retrieve
  the port numbers for all network adapters that have a
  connection to the portgroup(s)
.EXAMPLE
  PS> Get-dvVmPort
.EXAMPLE
  PS> Get-dvVmPort -VM VM1,VM2,VM3
.EXAMPLE
  PS> Get-VM -Name VM* | Get-dvVmPort
.EXAMPLE
  PS> Get-dvVmPort -PortGroup dvPg1
#>

  [CmdletBinding(DefaultParametersetName="VM")]
  param(
  [parameter(ParameterSetName="VM",ValueFromPipeline = $true)]
  [PSObject[]]$VM,
  [parameter(ParameterSetName="Portgroup")]
  [PSObject[]]$Portgroup
  )

  begin{
    $Nics = "VirtualE1000","VirtualE1000e","VirtualPCNet32","VirtualVmxnet",
    "VirtualVmxnet2","VirtualVmxnet3"
    $pgMask = Get-VirtualPortGroup | Sort-Object -Unique | %{$_.Name}
  }

  process{
    switch($PSCmdlet.ParameterSetName){
      "VM"{
        if($VM){
          if($VM[0] -isnot [String]){
            $VM = $VM | %{$_.Name}
          }
          $names = [string]::Join('|',($VM | %{$_}))
        }
        else{
          $names = ".+"
        }
        $VMs = @(Get-View -ViewType VirtualMachine -Filter @{"Name"=$names})
      }
      "Portgroup"{
        if($PortGroup[0] -isnot [String]){
          $PortGroup = $PortGroup | %{$_.Name}
        }
        $names = [string]::Join('|',($PortGroup | %{$_}))
        $PortGroups = @(Get-View -ViewType DistributedVirtualPortgroup -Filter @{"Name"=$names})
        $pgMask = $PortGroups | %{$_.Name}
        $VMs = $PortGroups | where {$_.Vm} | %{Get-View -Id $_.Vm} | Sort-Object -Property Name -Unique
      }
    }
    if($VMs){
      foreach($object in $VMs){
        $pgs = @{}
        Get-View $object.Network | %{
          if($_.Key){$key = $_.Key}else{$key = $_.MoRef.Value}
          $pgs.Add($key,$_.Name)
        }

        $object.Config.Hardware.Device |
        where {$Nics -contains $_.GetType().Name} | %{
          New-Object PSOBject -Property @{
            VM = $object.Name
            NIC = $_.DeviceInfo.Label
            PortGroup = &{
              if($_.Backing.Port){
                $key = $_.Backing.Port.PortgroupKey
              }
              else{
                $key = $_.Backing.Network.Value
              }
              $pgs[$key]
            }
            Port = $_.Backing.Port.PortKey
          } | where {$pgMask -contains $_.PortGroup}
        }
      }
    }
  }
}

Line 27-30: The function uses 2 parametersets, one to pass VMs and one to pass Portgroups. The default is VMs.

Line 29: Note that the script doesn’t accept Portgroups from the pipeline. Implementing such a feature is possible, but would require testing the type of the parameter value. I used the ‘keep it simple’ rule

Line 34-35: The script needs to test if the device is a NIC. This array should contain all the possible NIC types a VM can have.

Line 36,59,86: For the PortGroup parameter the script needs to test if the VM under investigation is connected to the requested portgroup. By default we take all the portgroups. If the PortGroup parameter is used, the script will only report on NICs connected to that portgroup.

Line 40-62: The Switch statement which handles the 2 parametersets.

Line 43-50: For the VM parameter the script can handle 1 or more VM names, or 1 or more VirtualMachineImpl objects.

Line 49: When no value is passed with the VM parameter, the script will take all VMs known in the connected vCenter. Since the script uses the Get-View cmdlet with the Filter parameter, the regular expression ‘.+’ is used to find all VMs.

Line 51,60: For both parametersets, the script passes a variable $VMs to the code after the Switch statement. The $VMs variable is populated with the VMs for which the portgroup port needs to be reported upon.

Line 57: The mask for the Get-View Filter parameter is generated. It’s of the form “vm1|vm2|vm3″

Line 65-69: The script uses a hash table to allow the portgroup name to be retrieved  with the portgroup key.

Line 71-86: For each NIC an object holding the information is generated.

Line 78,81: Note that the portgroup key is located in different properties, depending if the portgroup is on a regular vSwitch or a distributed vSwitch.

There are several ways you can call the function. Some examples

Get-dvVmPort | Sort-Object -Property VM,NIC | Select VM,NIC,PortGroup,Port

No parameter is passed, so the VM parameterset will be chosen. The function will report on all the available VMs. This will produce the following output.

Note that we had to use a Select-Object cmdlet to define the order of the displayed properties. In PowerShell v2 one doesn’t have any way to specify the order of the properties defined ona New-Object cmdlet. In PowerShell v3 this will change !

Another example, with a selected set of VM that are passed through the pipeline.

Get-VM -Name "VM[13]" | Get-dvVmPort | Sort-Object -Property VM,NIC | Select VM,NIC,PortGroup,Port

This will give

And finally an example with the PortGroup parameterset.

Get-dvVmPort -Portgroup (Get-VirtualPortGroup -Distributed) |  Select VM,NIC,PortGroup,Port

This call will produce a report on all the VMs that have a NIC connected to any of the distributed portgroups.

If we want to display this port information with each NIC connected to a VM, when we do a Get-NetworkAdapter, we can wrap the above logic in a New-VIProperty.

The New-VIProperty cmdlet allows us to extend the default set of properties that come with a PowerCLI object.

In this case the code is quite simple

New-VIProperty -Name dvPort -ObjectType NetworkAdapter `
  -Value {
    param($nic)

    $nic.ExtensionData.Backing.Port.PortKey
  } -Force | Out-Null

When we do

Get-VM -Name VM4 | Get-NetworkAdapter | Select Name,NetworkName,dvPort | Format-Table

We will get the following.

I hope this showed a bit the numerous possibilities you have with PowerCLI and PowerShell to tackle your vSphere administrative tasks.

Enjoy !

Unfortunately the SessionManager doesn’t hold any information from where the session was started.

But there are other ways of finding that information. The UserLoginSessionEvent object has a property, called ipAddress, that has the information we’re after.

Btw if you are only interested in looking for idle sessions, independent from which host they were started, there is a great post, called List and Disconnect vCenter Sessions on the PowerCLI blog.

function Get-VISessionInfo{
<#
.SYNOPSIS  Retrieve vCenter session information
.DESCRIPTION The function will retrieve the open vCenter
  session, including the IP address and hostname from where
  the session was started
.NOTES  Author:  Luc Dekens
.PARAMETER AllowedDifference
  The timestamps from the Session Manager entries and the
  event objects can sometimes differ, depending on the vCenter
  activity. The default is 1 second, but this can be changed
  with this parameter. The unit for this parameter is seconds.
.EXAMPLE
  PS> Get-VISessionInfo
#>

  param(
  [CmdletBinding()]
  [int]$AllowedDifference = 1
  )

  process{
    $sessMgr = Get-View SessionManager
    $oldest = ($sessMgr.SessionList | Sort-Object -Property LoginTime | Select -First 1).LoginTime
    $users = $sessMgr.SessionList | %{$_.UserName}
    $events = Get-VIEvent -MaxSamples ([int]::MaxValue) -Start $oldest.AddHours(-1) |
    where {$_ -is [VMware.Vim.UserLoginSessionEvent] -and $users -contains $_.UserName} |
    Sort-Object -Property CreatedTime

    $allowedDiffTS = New-TimeSpan -Seconds $AllowedDifference

    foreach($session in $sessMgr.SessionList){
      $events |
      where {[math]::Abs(($session.LoginTime.ToLocalTime() - $_.CreatedTime).Ticks) -lt $allowedDiffTS.Ticks -and
        $users -contains $_.UserName} | %{
        New-Object PSObject -Property @{
          "Session login" = $session.LoginTime
          UserName = $_.UserName
          IPAddress = $_.IPAddress
          Hostname = [System.Net.Dns]::GetHostEntry($_.IPAddress).HostName
        }
      }
    }
  }
}

Line 24: The script will look for the session with the oldest login time. This will allow us to limit the number of events that need to be retrieved.

Line 25: Besides the timestamps, the script will also check if the username that appears in an user session login event, is one of the users that has an open vCenter session.

Line 26-28: We retrieve the UserLoginSessionEvent for users that have an open vCenter session.

Line 30: The time difference we allow between the timestamp in the session and the corresponding UserLoginSessionEvent is converted to a TimeSpan object.

Line 34: To link a vCenter session to a UserLoginSessionEvent the script calculates the time difference between the timestamps in the UserLoginSessionEvent and the session object from the SessionManager. If the absolute time difference falls below the accepted time difference ($AllowedDifference), the event is linked to the session.

Line 36-41: The result is placed in the pipeline

Line 40: The script converts the IP address to the hostname with the GetHostEntry method.

The function is rather simple in use.

Get-VISessionInfo

And the result looks something like this.

Enjoy!

But while we are waiting for a new PowerCLI build that brings back the title bar text, you can fix this for yourself thanks to the proxy cmdlet feature.

Proxy cmdlets is (another) handy feature in PowerShell which allows you to modify and extend existing cmdlets. You can add parameters, change the output and do other crazy things. In the Extending and/or Modifing Commands with Proxies post from Jeffrey Snover you can find all the details.

In that same post you can also find the MetaProgramming module which makes it a breeze to customise cmdlets.

You just call the New-ProxyCommand and redirect the output to a .ps1 file, which you can then use to write your customisations for the cmdlet.

In this case I did that for the Connect-VIServer and Disconnect-VIServer cmdlets as follows

New-ProxyCommand Connect-VIServer > .\Connect-VIServer.ps1

New-ProxyCommand Disconnect-VIServer > .\Disconnect-VIServer.ps1

The resulting .ps1 files can now be edited to introduce our customisations to these cmdlets.

function Connect-VIServer{
  [CmdletBinding(DefaultParameterSetName='Default')]
  param(
  [Parameter(ParameterSetName='Default', Mandatory=$true, Position=0)]
  [ValidateNotNullOrEmpty()]
  [System.String[]]
  ${Server},

  [Parameter(ParameterSetName='Default')]
  [ValidateNotNull()]
  [ValidateRange(0, 65535)]
  [System.Int32]
  ${Port},

  [Parameter(ParameterSetName='Default')]
  [ValidateSet('http','https')]
  [System.String]
  ${Protocol},

  [Parameter(ParameterSetName='Default', ValueFromPipeline=$true)]
  [ValidateNotNullOrEmpty()]
  [System.Management.Automation.PSCredential]
  ${Credential},

  [Parameter(ParameterSetName='Default', ValueFromPipeline=$true)]
  [Alias('Username')]
  [System.String]
  ${User},

  [Parameter(ParameterSetName='Default')]
  [System.String]
  ${Password},

  [Parameter(ParameterSetName='Default')]
  [System.String]
  ${Session},

  [Parameter(ParameterSetName='Default')]
  [switch]
  ${NotDefault},

  [Parameter(ParameterSetName='Default')]
  [switch]
  ${SaveCredentials},

  [Parameter(ParameterSetName='Default')]
  [switch]
  ${AllLinked},

  [Parameter(ParameterSetName='Menu', Mandatory=$true)]
  [switch]
  ${Menu})

  begin
  {
    try {
      $outBuffer = $null
      if ($PSBoundParameters.TryGetValue('OutBuffer', [ref]$outBuffer))
      {
        $PSBoundParameters['OutBuffer'] = 1
      }
      $wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Connect-VIServer', [System.Management.Automation.CommandTypes]::Cmdlet)
      $scriptCmd = {& $wrappedCmd @PSBoundParameters }
      $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
      $steppablePipeline.Begin($PSCmdlet)
    } catch {
      Throw
    }
  }

  process
  {
    try {
      $steppablePipeline.Process($_)
    } catch {
      Throw
    }
    switch($defaultVIServers.Count){
      0 {
        $text = "Not Connected"
      }
      1 {
        $text = "Connected to " + $defaultVIServers[0].Name + " as " + $defaultVIServers[0].User
      }
      Default {
        $text = "Connected to " + $defaultVIServers.Count + " servers: "
        $text += [string]::Join(',',($defaultVIServers | %{$_.Name}))
      }
    }
    (Get-Host).UI.RawUI.WindowTitle = $text
  }

  end
  {
    try {
      $steppablePipeline.End()
    } catch {
      Throw
    }
  }
<#

.ForwardHelpTargetName Connect-VIServer
.ForwardHelpCategory Cmdlet

#>
}

Line 1,107: We make this a function
Line 78,90: The code we add to the original cmdlet. This will place the text in the title bar.

function Disconnect-VIServer{
  [CmdletBinding(SupportsShouldProcess=$true, ConfirmImpact='High')]
  param(
  [Parameter(Position=0, ValueFromPipeline=$true)]
  [ValidateNotNullOrEmpty()]
  [VMware.VimAutomation.ViCore.Types.V1.VIServer[]]
  ${Server},

  [switch]
  ${Force})

  begin
  {
    try {
      $outBuffer = $null
      if ($PSBoundParameters.TryGetValue('OutBuffer', [ref]$outBuffer))
      {
        $PSBoundParameters['OutBuffer'] = 1
      }
      $wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Disconnect-VIServer', [System.Management.Automation.CommandTypes]::Cmdlet)
      $scriptCmd = {& $wrappedCmd @PSBoundParameters }
      $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
      $steppablePipeline.Begin($PSCmdlet)
    } catch {
      Throw
    }
  }

  process
  {
    try {
      $steppablePipeline.Process($_)
    } catch {
      Throw
    }
    switch($defaultVIServers.Count){
      0 {
        $text = "Not Connected"
      }
      1 {
        $text = "Connected to " + $defaultVIServers[0].Name + " as " + $defaultVIServers[0].User
      }
      Default {
        $text = "Connected to " + $defaultVIServers.Count + " servers: "
        $text += [string]::Join(',',($defaultVIServers | %{$_.Name}))
      }
    }
    (Get-Host).UI.RawUI.WindowTitle = $text
  }

  end
  {
    try {
      $steppablePipeline.End()
    } catch {
      Throw
    }
  }
<#

.ForwardHelpTargetName Disconnect-VIServer
.ForwardHelpCategory Cmdlet

#>
}

Line 1,65: We make this a function
Line 36,48: The code we add to the original cmdlet. This will place the text in the title bar.

First you will need to dot-source the .ps1 files with the customised versions of both cmdlets.

. ./Connect-VIServer.ps1

. ./Disconnect-VIServer.ps1

We now have a function and a cmdlet for both.

Get-Command Connect-VIServer

Get-Command Disconnect-VIServer

But PowerShell will use a function before a cmdlet when both have the same name. Exactly what we need !

If you want to learn more about these precedences, do a

Get-Help About_command_precendence

Now we are ready to use our customised cmdlets. When we do a first connect

$vc = Connect-VIServer -Server MyVC

the PowerCLI window will show

When we connect an additional vSphere Server

$esx = Connect-VIServer -Server MyEsx1 -User root -Password MyPswd

the PowerCLI window will show.

When we disconnect from one of the vSphere Servers, the title bar will be updated as well.

Disconnect-VIServer -Server $vc

The title bar will show

There are of a couple of open problems

• The initial PowerCLI window shows "Not connected". This could eventually be solved by adapting the PowerCLI initialisation script, but I didn't want to change that script
• The Disconnect-VIServer cmdlet also accepts a [string] for the Server argument. The proxy cmdlet doesn't accept that, you will have to give it a VIServer object on the Server parameter.

Enjoy !

But what about the new ESX(i) hosts you will roll out in between root password changes and where you use a Host Profile to configure these new ESX(i) hosts ? Will you need to run a script after the deployment to change the root password ?

Turns out that you can easily update  the root password in your Host Profile with the help of an SDK method.

There are numerous scripts available in the blogosphere to accomplish this. But for good measure, this is one script that can do the task.

$currentPswd = "currentPassword"
$newPswd = "newPassword"

$excludeServers = "esx51","esx56"

$multiState = (Get-PowerCLIConfiguration).DefaultVIServerMode
$warnings = (Get-PowerCLIConfiguration).DisplayDeprecationWarnings
Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Confirm:$false -DisplayDeprecationWarnings:$false | Out-Null

Get-VMHost | where{$excludeServers -notcontains $_.Name.Split('.')[0]} | %{
  Connect-VIServer -Server $_.Name -User root -Password $currentPswd | Out-Null
  Write-Verbose "Connected to $_"
  Set-VMHostAccount -UserAccount root -Password $newPswd -Confirm:$false | Out-Null
  Disconnect-VIServer -Server $_.Name -Confirm:$false
}

Set-PowerCLIConfiguration -DefaultVIServerMode $multiState -DisplayDeprecationWarnings $warnings -Confirm:$false | Out-Null

Line 1-2:  Provide the current and the new password for the root account.

Line 4: The script allows for ESX(i) hosts whose root password should not be changed to the password specified in this run of the script. These ESX(i) hosts can excluded by adding their hostname to this array.

Line 6-8: The script needs to run in Multiple mode, in other words it needs connections to multiple vSphere servers at the same time. For the run of this script I also disable the warning messages for deprecated properties, this to avoid a long list of warning messages. The script remembers the current settings before changing them.

Line 10: The script gets all the ESX(i) servers and excludes the ones we defined in the array in line 4.

Line 11-14: The script makes a connection to the ESX(i) server and changes the password of the root account.

Line 12: If you want to track the ESX(i) hosts for which the script is changing the root password, you can set the $verbosePreference variable to Continue instead of the default SilentlyContinue.

Line 17: The script restores the PowerCLI Configuration settings.

When you use Host Profiles to configure your newly deployed ESX(i) servers, you will need to update the root account in those Host Profiles on a regular basis as well. That way the new ESX(i) hosts you roll out will immediately have the current root password.

function Set-VMHostProfileExtended{
<#
.SYNOPSIS  Update the root password in a Host Profile
.DESCRIPTION The function will update the root password in
  a Host Profile.
.NOTES  Author:  Luc Dekens
.PARAMETER Profile
  The Host Profile for which you want to change the root
  password. You can pass the name of the Host Profile
  or the VMHostProfile object
.PARAMETER AdminPassword
  The new root password.
.EXAMPLE
  PS> $prof = Get-VMHostProfile -Name MyProfile
  PS> Set-VMHostProfileExtended -Profile $prof -AdminPassword "abc"
#>

  param(
  [CmdletBinding()]
  [parameter(Mandatory = $true, ValueFromPipeline = $true)]
  [PSObject]$Profile,
  [string]$AdminPassword
  )

  begin{
    function Copy-Property ($From, $To, $PropertyName ="*")
    {
      foreach ($p in Get-Member -In $From -MemberType Property -Name $propertyName)
      {        trap {
          Add-Member -In $To -MemberType NoteProperty -Name $p.Name -Value $From.$($p.Name) -Force
          continue
        }
        $To.$($P.Name) = $From.$($P.Name)
      }
    }
  }

  process{
    if($Profile.GetType().Name -eq "string"){
      $Profile = Get-VMHostProfile -Name $Profile -Server $defaultVIServers[0]
    }

    $spec = New-Object VMware.Vim.HostProfileCompleteConfigSpec

    Copy-Property -From $Profile.ExtensionData.Config -To $spec

    $secpol = New-Object VMware.Vim.ProfilePolicy
    $secpol.Id = "AdminPasswordPolicy"
    $secpol.PolicyOption = New-Object VMware.Vim.PolicyOption
    $secpol.PolicyOption.Id = "FixedAdminPasswordOption"
    $secpol.PolicyOption.Parameter += New-Object VMware.Vim.KeyAnyValue
    $secpol.PolicyOption.Parameter[0].Key = "password"
    $secpol.PolicyOption.Parameter[0].Value = New-Object VMware.Vim.PasswordField
    $secpol.PolicyOption.Parameter[0].Value.Value = $AdminPassword
    $spec.ApplyProfile.Security.Policy = @($secpol)

    $hp.ExtensionData.UpdateHostProfile($spec)

    Get-VMHostProfile -Name $Profile.Name
  }
}

Line 26-35: The function needs to copy all the Config properties from the HostProfile to the HostProfileCompleteConfigSpec object. Instead of reinventing the wheel, I used a function called Copy-Property function from Dennis Verwiej.

Line 39-41: My simplistic Object By Name (OBN) implementation.

Line 45: The copy of the Config property to the HostProfileCompleteConfigSpec object.

Line 47-55: To the copied HostProfile configuration the script adds the AdminPasswordPolicy definitions.

Line 57: The HostProfile is updated with the UpdateHostProfile method.

Line 59: To emulate the behaviour of the Set-VMHostProfile cmdlet, the function places the updated VMHostProfile object on the pipeline.

The function to update the Host Profile can be called with the Host Profile as a parameter.

$hostProf = "MyProfile"
$newProf = Set-VMHostProfileExtended -Profile $hostProf -AdminPassword "secret"

or

$hostProf = Get-VMHostProfile -Name MyProfile
$newProf = Set-VMHostProfileExtended -Profile $hostProf -AdminPassword "secret"

Or you can place the Host Profile on the pipeline.

Get-VMHostProfile -Name MyProfile | Set-VMHostProfileExtended -AdminPassword "secret"

Notice that I called the function Set-VMHostProfileExtended. The reason for that is that one can update several other settings in a Host Profile this way. I’ll probably add some other settings to the function in a later stage.

Enjoy !

The first release of the Cloud snapin brings us primarily Get type cmdlets. But there is more, just as the Get-View cmdlet opened up access to the vSphere API, the new Get-CIView cmdlet, and the ExtensionData property, opens up access  to all the vCD APIs.

First a quick list of all the cmdlets that are available in the Cloud snapin.

PS: the list above has been created with the script from my PowerCLI cmdlet XRef – Another look post.

The PowerCLI help pages are available online.

Btw the CI noun prefix that you will see as a prefix to most of the Cloud cmdlets nouns, stands for Cloud Infrastructure.

To start a session you use the Connect-CIServer cmdlet, similar to what you do with the Connect-VIServer cmdlet. The difference is that you will have to specify a vCloud Director server instead of a vSphere Server.

Connect-Ciserver -Server MyVCD -User Luc -Password MyPswd

And you’ll immediately notice a first change, the Certificate warning message has changed. You are prompted to answer with one of the listed options.

Does this mean you will have to do this every time (provided you don’t update the Certificate) ?
No, the Set-PowerCLIConfiguration cmdlet has been extended with a new parameter, called InvalidCertificateAction. You can provide the parameter with one of the values of the BadCertificateAction enumeration, and PowerCLI will take that as the default action for future connects.

Notice that we didn’t specify an Organization name, through the Org parameter, to the Connect-CIServer cmdlet. That means your session will get connected to the System organization.

Once you are connected, you can start having a look around with the help of all the Get type cmdlets. The VMs in the Cloud

Get-CIVM

returns something like

The Roles that are present

Get-CIRole

which gives

And the available vApps in this cloud

Get-CIvApp

This tells us there currently 4 vApps present

But is this all we can do ? Only produce reports of what is available in our cloud ?

No, luckily there are already a couple of other cmdlets that will allow you to populate your cloud.

Let’s take the case where we want to import a VM from our vCenter into our Cloud.

First connect to the vCenter server, then get the VM you want to import and pass the VM to the Import-CIVApp cmdlet. Note that for the creation of this new vApp you will have to provide an Organization VDC. The organization VDCs can be listed with the Get-OrgVdc cmdlet.

Connect-VIServer -Server MyVC

$orgVdc = Get-OrgVdc -Name MyOrgVdc

Get-VM -Name TestVM2 | Import-CIVApp -OrgVdc $orgVdc -Name TestVapp

You will first see that VM, called TestVM2, is cloned in your vCenter, followed by an import of the clone into your Cloud. This import will display a progress bar.

The VM will be part of the new Cloud vApp called TestVapp.

And the imported VM is in the new vApp called TestVapp.

Adding additional VMs to this vApp is done this way.

Get-VM -Name TestVM3 | Import-CIVApp -Name TestVapp

That’s all there is to it.

Now what if you want to do something that is not (yet) covered by the Cloud snapin cmdlets ?

With the Get-CIView cmdlet and the ExtensionData property on the Cloud objects, you can have access to all the vCloud object properties and methods.

If you intend to use these vCloud .Net object, I advise to have the reference guide available. Download the VMware vCloud SDK for .Net file, extract the files from the ZIP archive and then open .\VMware-vCloudDirector-.NetSDK-1.5.0.2\Docs\ndoc3_msdn_temp\index.html from the folder where you unzipped the archive.

A quick sample, where we list the  methods accessible through the ExtensionData of a VM.

The other way to get there is through the Get-CIView cmdlet. This gives access to the same methods (and properties).

The access to these methods comes in handy when we need to perform some action that is not available through the cmdlets.

As an example, we want to delete the VM called TestVM3 from the TestVapp vApp. With the access to the vCD API this is now a piece of cake.

That was my short tour of the Cloud snapin, but it only scratched the surface. There’s tons more of good stuff to be discovered.

Before I forget, make sure to select the Cloud snapin when you install/upgrade PowerCLI 5.0.1. By default the Cloud snapin is not installed !

Needless to say that there are other improvements in PowerCLI 5.0.1. One that I will definitely have a closer look at is the new XML feature that is provided with the Get-EsxCli cmdlet.

And btw, the mixup of the FreeSpaceGB and CapacityGB properties, both in the objects returned by the Get-Datastore cmdlet, is fixed

Enjoy PowerCLI 5.0.1 !

The official prerequisites are all documented in the help for the Invoke-VMScript cmdlet. The following table is a summary.

From my own experience and from several posts in the PowerCLI Community, I have 2 additional prerequisites.

• The cmdlet seems to work most of the time when the guest OS is Windows 2008 R2. Note that there have been reports about errors with this OS. In the current PowerCLI build Windows 2008 R2 is not in the list of supported guest OS.
• When you use the hostname in the Connect-VIServer cmdlet, the Invoke-VMScript doesn’t seem to work. When you do the Connect-VIServer with the FQDN or the IP address, the cmdlet works. The error message looks like this

The list of my 2 non-official prerequisites

function Test-InvokeVMScript{
<#
.SYNOPSIS  Test if Invoke-VMScript will work
.DESCRIPTION The function verifies if all prerequisites
  are present to use the Invoke-VMScript cmdlet.
.NOTES  Author:  Luc Dekens
.PARAMETER VM
  The virtual machine for which you want to test the
  prerequisites. You can pass the name of the virtual
  machine or the VM object
.PARAMETER Official
  This switch specifies if only the official prerequistes
  should be verified or not. The default value is $True,
  so only the official prerequisites
.PARAMETER Detail
  Switch that specifies if all the prerequisite details
  should be returned or not. The default is $False
.EXAMPLE
  PS> Test-InvokeVMScript -VM $vm -Detail
.EXAMPLE
  PS> Get-VM VM* | Test-InvokeVMScript -Official:$false
#>

  param(
  [CmdletBinding()]
  [parameter(Mandatory = $true, ValueFromPipeline = $true)]
  [PSObject]$VM,
  [switch]$Official = $True,
  [switch]$Detail
  )

  begin{
    $pCLIMajor,$pCLIMinor = Get-PowerCLIVersion | %{$_.Major,$_.Minor}
    $apiMajor,$apiMinor = (Get-View ServiceInstance).Content.About.ApiVersion.Split('.')
  }

  process{
    if($VM.GetType().Name -eq "string"){
      $VM = Get-VM -Name $VM
    }

    $condPoweredOn = $condCpu = $condTools = $condPort = $condRead = $condRole = $condOS = $False

    # Common prerequisites

    # Powered on
    if($vm.PowerState -eq "PoweredOn"){
      $condPoweredOn = $True
    }

    # 32-bit engine
    if ($env:Processor_Architecture -eq "x86"){
      $condCpu = $true
    }

    # Tools installed
    if($VM.Guest.State -eq "Running" -and $VM.ExtensionData.Summary.Guest.ToolsVersionStatus -eq "guestToolsCurrent"){
      $condTools = $True
    }

    # Port 902 open
    $originalEA = $ErrorActionPreference
    $ErrorActionPreference = “SilentlyContinue”
    $socket = New-Object Net.Sockets.TcpClient
    $socket.Connect($VM.Host.Name,902)
    if($socket.Connected){
      $condPort = $True
      $socket.Close()
    }
    Remove-Variable -Name socket -Confirm:$false
    $ErrorActionPreference = $originalEA

    # Folder read access
    $datastore,$file = $VM.ExtensionData.Config.Files.VmPathName.Split(']')
    $datastoreName = $datastore.Trim('[')
    $fileName = $file.Split('/')[1]
    $file = $file.TrimStart(' ')
    $ds = Get-Datastore -Name $datastoreName
    New-PSDrive -Location $ds -Name DS -PSProvider VimDatastore -Root '\' | Out-Null
    $currentProgPref = $ProgressPreference
    $ProgressPreference = 'SilentlyContinue'
    Copy-DatastoreItem -Item ('DS:\' + $file) -Destination $env:Temp -ErrorAction SilentlyContinue
    $ProgressPreference = $currentProgPref
    Remove-PSDrive -Name DS
    $path = $env:Temp + '\' + $fileName
    $condRead = Test-Path -Path $path
    if($condRead){
      Remove-Item -Path $path -Confirm:$false
    }

    # Privilege
    $authMgr = Get-View AuthorizationManager
    $role = $authMgr.RoleList | where {$vm.ExtensionData.EffectiveRole -eq $_.RoleId}
    $condRole = $role.Privilege -contains "VirtualMachine.Interact.ConsoleInteract"

    # Supported OS
    $supportedOS = "winLonghornGuest",  # Windows 2008
    "winLonghorn64Guest",               # Windows 2008 (64 bit)
    "windows7Guest",                     # Windows 7
    "windows7_64Guest",                 # Windows 7 (64 bit)
    "windows7Server64Guest",            # Windows Server 2008 R2 (64 bit)
    "winXPProGuest",                     # Windows XP Professional
    "winXPPro64Guest",                   # Windows XP Professional Edition (64 bit)
    "winXPHomeGuest",                   # Windows XP Home Edition
    "rhel5Guest",                       # Red Hat Enterprise Linux 5
    "rhel5_64Guest",                     # Red Hat Enterprise Linux 5 (64 bit)
    "rhel6Guest",                       # Red Hat Enterprise Linux 6
    "rhel6_64Guest"                     # Red Hat Enterprise Linux 6 (64 bit)
    $guestId = $VM.ExtensionData.Summary.Guest.GuestId
    if($guestId -like "winNet*" -or $supportedOS -contains $guestId){
      $condOS = $true
    }

    # Version dependent prerequisites
    $propertiesVix =[System.Diagnostics.FileVersionInfo]::GetVersionInfo($env:programfiles + '\VMware\VMware VIX\VixCOM.dll')
    $majorVix = $propertiesVix.FileMajorPart
    $minorVix = $propertiesVix.FileMinorPart
    $buildVix = $propertiesVix.FileBuildPart
    $versionVix = ([string]$majorVix + '.' + [string]$minorVix + '.' + [string]$buildVix)

    if(($pCLIMajor -eq 5 -and $versionVix -eq '1.10.0') -or
    ($pCLIMajor -eq 4 -and $versionVix -eq '1.6.2')){
      $condVix = $true
    }

    # Unofficial conditions
    if(!$Official){
      $condFQDN_U = $condOS_U = $False

      # OS that seems to work (most of the time)
      if($guestId -like "windows7Server64Guest"){  # Windows Server 2008 R2 (64 bit)
        $condOS_U = $True
      }

      # Short name
      $condFQDN_U = $global:DefaultVIserver.Name.Contains('.')
    }

    # Result
    if($Official){
      $result = $condPoweredOn -and $condCpu -and $condTools -and
        $condPort -and $condRead -and $condRole -and $condOS
    }
    else{
      $result = $condPoweredOn -and $condCpu -and $condTools -and
        $condPort -and $condRead -and $condRole -and
        ($condOS -or $condOS_U) -and $condFQDN_U
    }

    $resultObj = New-Object PSObject -Property @{
      VM = $VM.Name
      OK = $result
    }
    if($Detail){
      $resultObj = $resultObj |
      Add-Member -Name PoweredOn -Value $condPoweredOn -MemberType NoteProperty -PassThru |
      Add-Member -Name X86Engine -Value $condCpu -MemberType NoteProperty -PassThru |
      Add-Member -Name ToolsInstalled -Value $condTools -MemberType NoteProperty -PassThru |
      Add-Member -Name Port902Open -Value $condPort -MemberType NoteProperty -PassThru |
      Add-Member -Name FolderReadAccess -Value $condRead -MemberType NoteProperty -PassThru |
      Add-Member -Name PrivilegeConsoleInteraction -Value $condRole -MemberType NoteProperty -PassThru |
      Add-Member -Name SupportedOS -Value $condOs -MemberType NoteProperty -PassThru
      if(!$Official){
        $resultObj = $resultObj |
        Add-Member -Name FQDNorIPConnection -Value $condFQDN_U -MemberType NoteProperty -PassThru
      }
    }
    $resultObj
  }
}

Line 32-35: Retrieve some properties the script will use later.

Line 38-40: My poor man’s Object By Name (OBN) implementation.

Line 42: Set all prerequisites to $false

Line 73-89: To test if the caller has read access to the VM folder, the script will copy the VMX file to local storage.

Line 82: This is the major bottleneck in the function. The Copy-DatastoreItem cmdlet is quite slow compared to the other PowerCLI cmdlets.

Line 110: All Windows Server 2003 variations have a guestId that starts with “winNet”. See the VirtualMachineGuestOsIdentifier enumeration.

Line 131-133: Chekc if the guest OS is Windows 2009 R2. If you don’t want this test, just comment out these lines.

Line 136: By testing if there any dots in the name, we can verify if it is a Fully Qualified Domain Name or an IP address.

A very straightforward example

$vm = Get-VM -Name MyVM
Test-InvokeVMScript -VM $vm

This will return a simple object, where the OK property will say if the prerequisites are met or not.

If we want to know which of the prerequisites failed, we can do

$vm = Get-VM -Name MyVM
Test-InvokeVMScript -VM $vm -Detail

From the output we can immediately see why the Invoke-VMScript cmdlet would fail.

Looks like we are not running this in a 32-bit engine.

To also see my non-official prerequisites, we can do

Get-VM MyVM2 | Test-InvokeVMScript -Official:$false -Detail

This produces the following

All the official prerequisites are fulfilled, but it looks as if our Connect-VIServer might have been done with a short hostname.

Let me know if you know of any other prerequisites, and I will add them to the function.

Enjoy the function.

With VMFS5 comes a bunch of new features. Just to name a few:

• 64TB VMFS Volumes in 1 extent
• 64TB physical RDM
• Unified block size of 1MB
• Support for more files (> 100000)

For a complete list of the features that VMFS5 introduces, have a look at Cormac‘s post, called vSphere 5.0 Storage Features Part 1 – VMFS-5.

The vSphere 5 Client has an option to upgrade your VMFS3 datastores to VMFS5 datastores.

Handy option, but we want to automate this of course

And as a bonus I’ll throw in a function to get the partition information from a datastore.

function ConvertTo-Vmfs5{
<#
.SYNOPSIS  Upgrade a datastore to VMFS5
.DESCRIPTION The function will convert the datastores that
  are passed to it to VMFS5.
.NOTES  Author:  Luc Dekens
.PARAMETER Datastore
  The datastore(s) to be upgraded
  The parameter accepts a string or an object returned by the
  Get-Datastore cmdlet.
.EXAMPLE
  PS> ConvertTo-Vmfs5 -Datastore "DS*"
.EXAMPLE
  PS> Get-Datastore -Name "DS1" | ConvertTo-Vmfs5
#>

  param(
  [CmdletBinding()]
  [parameter(Mandatory = $true, ValueFromPipeline = $true)]
  [PSObject[]]$Datastore
  )

  process{
    foreach($ds in $Datastore){
      if($ds.getType().Name -eq "string"){
        $ds = Get-Datastore -Name $ds
      }
      $poweredHosts = $ds.ExtensionData.Host | %{Get-View -Id $_.Key} |
      where {$_.Runtime.PowerState -eq "PoweredOn"}

      $oldHost = $poweredHosts |
      where {$_.Capability.SupportedVmfsMajorVersion -notcontains 5}
      if($oldHost){
        Write-Warning "One of the connected hosts doesn't support VMFS5"
        exit
      }
      $vmfsPath = $ds.ExtensionData.Host[0].MountInfo.Path
      $storSys = Get-View ($poweredHosts | Get-Random).ConfigManager.StorageSystem

      $storSys.UpgradeVmfs($vmfsPath)
    }
  }
}

function Get-VmfsPartitionInfo{
<#
.SYNOPSIS  Retrieves partition info for a datastore
.DESCRIPTION The function will retrieve partition information
  for one or more datastores
.NOTES  Author:  Luc Dekens
.PARAMETER Datastore
  The datastore(s) for which the partition info shall be
  returned. The parameter accepts a string or an object
  returned by the Get-Datastore cmdlet.
.EXAMPLE
  PS> Get-VmfsPartitionInfo -Datastore "DS*"
.EXAMPLE
  PS> Get-Datastore -Name "DS1" | Get-VmfsPartitionInfo
#>
  param(
  [CmdletBinding()]
  [parameter(Mandatory = $true, ValueFromPipeline = $true)]
  [PSObject[]]$Datastore
  )

  process{
    foreach($ds in $Datastore){
      if($ds.getType().Name -eq "string"){
        $ds = Get-Datastore -Name $ds
      }
      $poweredHosts = $ds.ExtensionData.Host | %{Get-View -Id $_.Key} |
      where {$_.Runtime.PowerState -eq "PoweredOn"}
      $storSys = Get-View ($poweredHosts | Get-Random).ConfigManager.StorageSystem

      $ds.ExtensionData.Info.Vmfs.Extent | %{
        $devicePath = "/vmfs/devices/disks/" + $_.DiskName
        $storSys.RetrieveDiskPartitionInfo($devicePath) | %{
          New-Object PSObject -Property @{
            Name = $ds.Name
            Version = $ds.FileSystemVersion
            Device = $_.DeviceName
            PartitionFormat = $_.Spec.PartitionFormat
            BlockSizeMB = $ds.ExtensionData.Info.Vmfs.BlockSizeMb
            Blocks = $_.Layout.Total.Block
          }
        }
      }
    }
  }
}

Line 25-27: A rather simple Object By Name implementation.

Line 28-29: Collect the hosts, connected to the datastore, that are powered on. The reason is that we can’t use the UpgradeVmfs method via the StorageSystem of a powered off host.

Line 31-36: Check if all the powered on and connected hosts support VMFS5. If not, leave the function.

Line 37: Get the devicepath to the datastore.

Line 38: Get the HostStorageSystem. Note that the function randomly selects 1 host from the powered on hosts. There is no real reason to do this, but I wanted to spread the method call over all available hosts.

Line 40: Convert the datastore to VMFS5

Line 68-70: Another example of my rather simple Object By Name implementation.

Line 71-73: We randomly take 1 of the connected hosts to fetch the HostStorageSystem.

Line 75: We loop through each VMFS extent of the datastore

Line 76-77: The function uses the RetrieveDiskPartitionInfo method to fetch the partition information.

Line 78-85: The function fetches the information for each partition and puts it on the pipeline as a PSObject.

In our vSphere 4 environment we have a number of VMFS3 datastores.

First, I use the Get-VmfsPartition function to check the partitioninfo of each datastore.

Get-Datastore DS* | Get-VmfsPartitionInfo | ft -AutoSize

The result.

Notice the BlockSizeMB column in the output, all 4 possible blocksizes for VMFS3 datastores are present.

Let’s upgrade these VMFS3 datastores to VMFS5 datastores.

Get-Datastore DS* | ConvertTo-Vmfs5

The convert function produces no output, but we can check what the new properties are with the Get-VmfsPartitionInfo function.

The VMFS version is 5.54, so the conversion worked.

But the attentive viewer might have noticed a couple of values he didn’t expect.

• The PartitionFormat still says ‘MBR’. Shouldn’t that be ‘GPT’ ?
• The BlocksizeMB stayed the same as before the VMFS5 conversion. Shouldn’t that be 1MB for VMFS5 datastores ?

The answer to both questions can be found in Cormac’s post called vSphere 5.0 Storage Features Part 1 – VMFS-5.

• A converted datastores keeps the ‘MBR’ format until it grows bigger than 2TB.
• A converted datastores keeps the original VMFS3 blocksize.

And I want to repeat Cormac’s final advise in his post, if you have the luxury to do so, it’s better to create new VMFS5 datastores instead of converting VMFS3 datastores !

Derived from the Get-VmfsPartitionInfo function, I created a New-VIProperty definition to return the format of the first datastore partition.

New-VIProperty -Name PartitionFormat -ObjectType Datastore `
  -Value {
    param($ds)

    $storSys = Get-View (Get-View $ds.ExtensionData.Host[0].Key).ConfigManager.StorageSystem
    $partInfo = $storSys.RetrieveDiskPartitionInfo("/vmfs/devices/disks/" +
      $ds.ExtensionData.Info.Vmfs.Extent[0].DiskName)
    $partInfo[0].Spec.PartitionFormat
  } -Force | Out-Null

Note that you will only get the partition format (MBR or GPT) when you use this in a vSphere 5, or higher, environment. The partitionFormat property in the HostDiskPartitionSpec object is only available since API 5.

Enjoy !

Note that this feature requires distributed Switches (dvSwitch). In fact I could have also written this post in my dvSwitch series with the title dvSwitch scripting – Part 10 – NetIOC.

function New-dvSwNetworkResourcePool{
<#
.SYNOPSIS Create a user-defined network resource pool
.DESCRIPTION The function will create a user-defined
  resourcepool on a specific dvSwitch.
.NOTES  Author:  Luc Dekens
.PARAMETER dvSw
  The dvSwitch on which the user-defined network resource pool
  will be created.
.PARAMETER Name
  The name of the user-defined network resource pool.
.PARAMETER Description
  The description of the user-defined network resource pool.
.PARAMETER QoSTag
  The QoSTag that will be assigned to the user-defined
  network resource pool. A value from the range 0-7.
.PARAMETER Limit
  The QoSTag that will be assigned to the user-defined
  network resource pool. A value from the range 0-7.
.PARAMETER Shares
  The number of shares allocated. Can be "low","normal","high"
  or a number (a relative value compared with the shares value
  on other resource pools in case of contention)
.EXAMPLE
  PS> New-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool1" `
  PS>> -Description "Dutch VMUG 2011"
.EXAMPLE
  PS> New-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool2" `
  PS>> -Description "Dutch VMUG 2011" -Shares 75 -QoSTag 3
#>
  param(
  [parameter(Position = 0, Mandatory = $true, ValueFromPipeline = $true)]
  [VMware.Vim.VmwareDistributedVirtualSwitch]$dvSw,
  [parameter(Position = 1, Mandatory = $true)]
  [string]$Name,
  [parameter(Position = 2)]
  [string]$Description,
  [string]$QoSTag,
  [long]$Limit = -1,
  [string]$Shares = "normal"
  )

  $spec = New-Object VMware.Vim.DVSNetworkResourcePoolConfigSpec
  $spec.Name = $Name
  $spec.Description = $Description
  $spec.Key = "dummy"
  $spec.allocationInfo = New-Object VMware.Vim.DVSNetworkResourcePoolAllocationInfo
  $spec.allocationInfo.Limit = $Limit
  $spec.allocationInfo.priorityTag = &{if($QoSTag){[int]$QoSTag}}
  $spec.allocationInfo.Shares = New-Object VMware.Vim.SharesInfo
  if("high","low","normal" -contains $Shares){
    $spec.allocationInfo.Shares.Level = $Shares
  }
  else{
    $spec.allocationInfo.Shares.Level = "custom"
    $spec.allocationInfo.Shares.Shares = [int]$Shares
  }

  $dvSw.AddNetworkResourcePool(@($spec))
}

function Remove-dvSwNetworkResourcePool{
<#
.SYNOPSIS Remove a user-defined network resource pool
.DESCRIPTION The function will remove a user-defined
  resource pool from a specific dvSwitch.
.NOTES  Author:  Luc Dekens
.PARAMETER dvSw
  The dvSwitch on which the user-defined network resource pool
  shall be removed.
.PARAMETER Name
  The name of the user-defined network resource pool.
.EXAMPLE
  PS> Remove-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool1"
#>
  param(
  [parameter(Position = 0, Mandatory = $true, ValueFromPipeline = $true)]
  [VMware.Vim.VmwareDistributedVirtualSwitch]$dvSw,
  [parameter(Position = 1, Mandatory = $true)]
  [string]$Name
  )

  $pool = $dvSw.NetworkResourcePool | where {$_.Name -eq $Name}
  if($pool){
    $dvSw.RemoveNetworkResourcePool($pool.Key)
  }
}

function Get-dvSwNetworkResourcePool{
<#
.SYNOPSIS Retrieve user-defined network resource pool(s)
.DESCRIPTION The function return all or a specific set
  of user-defined network resource pools from a dvSwitch
.NOTES  Author:  Luc Dekens
.PARAMETER dvSw
  The dvSwitch from which the user-defined network resource pool
  shall be retrieved.
.PARAMETER Name
  The name of the user-defined network resource pool.
  If no name is specified, all user-defined network
  resource pools on the dvSwitch will be returned.
.EXAMPLE
  PS> Get-dvSwNetworkResourcePool -dvSw $dvSw
.EXAMPLE
  PS> Get-dvSwNetworkResourcePool -dvSw $dvSw -Name "Net*"
#>
  param(
  [parameter(Position = 0, Mandatory = $true, ValueFromPipeline = $true)]
  [VMware.Vim.VmwareDistributedVirtualSwitch]$dvSw,
  [parameter(Position = 1)]
  [string]$Name = "*"
  )

  $dvSw.UpdateViewData()
  $dvSw.NetworkResourcePool | where {$_.Name -like $Name} | %{
    New-Object PSObject -Property @{
      Name = $_.Name
      Description = $_.Description
      Limit = $_.AllocationInfo.Limit
      QoSTag = &{if($_.AllocationInfo.PriorityTag -eq 0){"none"}else{$_.AllocationInfo.PriorityTag}}
      Shares = &{if($_.AllocationInfo.Shares.Level -eq "custom"){$_.AllocationInfo.Shares.Shares}else{$_.AllocationInfo.Shares.Level}}
    }
  }
}

function Set-dvSwSIOC{
<#
.SYNOPSIS Enable/disable NetIOC on a dvSw
.DESCRIPTION The function will enable or disable
  I/O Control on a dvSwitch
.NOTES  Author:  Luc Dekens
.PARAMETER dvSw
  The dvSwitch on which I/O Control will be
  enabled/disabled
.PARAMETER Enabled
  A switch that allows control of I/O Control. When
  the switch is $True, IOC will be enabled. If $False
  IOC will be disabled
.EXAMPLE
  PS> Set-dvSwSIOC -dvSw $dvSw -Enabled
#>
  param(
  [parameter(Position = 0, Mandatory = $true, ValueFromPipeline = $true)]
  [VMware.Vim.VmwareDistributedVirtualSwitch]$dvSw,
  [parameter(Position = 1)]
  [switch]$Enabled
  )

  $dvSw.EnableNetworkResourceManagement($Enabled)
}

function Get-dvSwSIOC{
<#
.SYNOPSIS Retrieve the IOC status
.DESCRIPTION Returns the status of IOC on a dvSwitch
.NOTES  Author:  Luc Dekens
.PARAMETER dvSw
  The dvSwitch from which the status of I/O Control will be
  returned
.EXAMPLE
  PS> Get-dvSwSIOC -dvSw $dvSw -Enabled
#>
  param(
  [parameter(Position = 0, Mandatory = $true, ValueFromPipeline = $true)]
  [VMware.Vim.VmwareDistributedVirtualSwitch]$dvSw
  )

  $dvSw.UpdateViewData()
  New-Object PSObject -Property @{
    Name = $dvSw.Name
    SIOCEnabled = $dvSw.Config.NetworkResourceManagementEnabled
  }
}

Line 38: Although the QosTag is an [int], we use the [string] cast. Otherwise the absence of the parameter would set QosTag to 0, which is a valid 802.1p value.

Line 38-40: The absence of these 3 parameters on a call to the function will create a user-defined network resource pool with the same settings as if the resource pool was created in the vSphere Client.

Line 51-57: If the Shares parameter is not set to “normal”, “high” or “low”, it will be set to “custom” and the Shares value will be used as an [int] value.

Line 80: The removal of a user-defined network resource pool requires the Name parameter to be set.

Line 111: If no Name parameter is used, all the user-defined network resource pools on the dvSwitch will be returned.

Line 114: To get the most recent data, the script refreshes the dvSwitch object.

Line 120: This test will make sure, that the function returns the same values as displayed in the vSphere Client.

Line 121: When the Shares level is “custom”, the [int] value of the share will be returned.

We start with an empty dvSwitch. The Get-dvSwitch function can be found in my dvSwitch scripting – Part 2 – dvPortgroup post.

First we get the dvSwitch and we get a list of the current network resource pools.

$dvSw = Get-dvSwitch -DatacenterName "DC1" -dvSwitchName "dvSw1"
Get-dvSwNetworkResourcePool -dvSw $dvSw | ft -AutoSize

This will return the system network resource pools.

The same information as we can see in the vSphere Client under System network resource pools.

Note that NetIOC is not enabled by default.

Next we create a number of user-defined network resource pools.

New-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool1" -Description "Dutch VMUG 2011"
New-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool2" -Description "Dutch VMUG 2011" -Shares 75 -QoSTag 3
New-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool3" -Description "Dutch VMUG 2011" -Limit 4500
Get-dvSwNetworkResourcePool -dvSw $dvSw | ft -AutoSize

The result shows the 3 newly created network resource pools.

And we see the same in the vSphere Client.

As we noticed earlier, NetIOC is not enabled by default. Let’s display the current setting.

Get-dvSwSIOC -dvSw $dvSw | ft -AutoSize

We change the setting and retrieve the value again

Set-dvSwSIOC -dvSw $dvSw -Enabled
Get-dvSwSIOC -dvSw $dvSw | ft -AutoSize

This gives

To conclude we will clean up the demo pools and disable NetIOC again.

Set-dvSwSIOC -dvSw $dvSw -Enabled:$false

Remove-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool1"
Remove-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool2"
Remove-dvSwNetworkResourcePool -dvSw $dvSw -Name "NetPool3"

Enjoy !

A single vMotion can now scale over multiple NICs. This feature can use a regular vSwitch or distributed vSwitch.On YouTube there are 2 videos, uploaded by VMwareKB, that show how to configure such a vMotion enabled multi-NIC vSwitch, regular and distributed.

Very useful videos, but as you can imagine, I wanted to automate this. No GUI clicking for me 

function Set-vMotionMultiNic{
<#
.SYNOPSIS  Configure multi-NIC vMotion
.DESCRIPTION The function will configure multi-NIC vMotion
  enabled portgroups on a regular vSwitch
.NOTES  Author:  Luc Dekens
.PARAMETER VMHost
  The ESXi host where the vMotion enabled portgroups shall be
  configured.
  The parameter accepts a string or the object returned by the
  Get-VMHost cmdlet.
.PARAMETER VirtualSwitch
  The virtual switch on which the vMotion enabled portgroups
  shall be configured.
  The parameter accepts a string or the object returned by the
  Get-VirtualSwitch cmdlet.
.PARAMETER pNic
  An array with the vnics that shall be used to configure the
  portgroups. Depending on the number of provided vnics, the
  function will create the optimal number of portgroups.
  The arrays on pNic, IPaddress and SubnetMask shall have the
  same number of elements.
.PARAMETER IpAddress
  An array with the IP addresses that shall be used on the
  portgroups
.PARAMETER SubnetMask
  An array with the subnetmasks.
.EXAMPLE
  PS> Set-vMotionMultiNic -VMHost MyESX -VSwitch MyvSw `
  PS>>   -pNic "vmnic2","vmnic3","vmnic4" `
  PS>>   -IpAddress "192.168.1.1","192.168.1.2","192.168.1.3" `
  PS>>   -SubnetMask (,"255.255.255.0" * 3)
#>
  param(
    [psobject]$VMHost,
    [psobject]$VirtualSwitch,
    [string[]]$pNic,
    [string[]]$IpAddress,
    [string[]]$SubnetMask
  )56

  if($VMHost.getType().Name -eq "string"){
    $VMHost = Get-VMHost -Name $VMHost
  }
  if($VMHost.ApiVersion.Split('.')[0] -lt 5){
    Write-Warning "MultiNic for vMotion requires at least ESXi 5.0"
    exit
  }

  if($VirtualSwitch.getType().Name -eq "string"){
    $VirtualSwitch = $VMHost | Get-VirtualSwitch -Name $VirtualSwitch
  }
  $indices = 0..($pNic.Count - 1)
  foreach($i in $indices){
    $pg = New-VirtualPortGroup -Name ("vMotion-{0:d2}" -f ($i + 1)) -VirtualSwitch $VirtualSwitch
    New-VMHostNetworkAdapter -VMHost $VMHost -VirtualSwitch $VirtualSwitch -PortGroup $pg -IP $IpAddress[$i] -SubnetMask $SubnetMask[$i] -VMotionEnabled:$true | Out-Null
    Get-NicTeamingPolicy -VirtualPortGroup $pg |
    Set-NicTeamingPolicy -MakeNicActive $pNic[$i] -MakeNicStandby $pNic[($indices | where {$_ -ne $i})] |Out-Null
  }
}

Line 42-44: A simple Object By Name (OBN) implementation for the ESXi host

Line 45-48: A check if we are configuring this for at least a vSphere 5 server

Line 50-52: A simple Object By Name (OBN) implementation for the regular vSwitch

Line 53: When the function is called with ‘n’ vnics, it will have to create ‘n’ portgroups. This calculation creates the list of suffixes that will be used on the portgroup names.

Line 55: The creation of the portgroup. Note how the function adds a 2 digit suffix with the -format operator to the basename (‘vMotion’)

Line 56: Set the IP address and subnetmask

Line 57-58: The Teaming is configured in the same way the VMwareKB video demonstrates.

To demonstrate the function, I will use a simple configuration. We have 1 regular vSwitch that has 3 vnics connected to it.

We call the function

$IP = "192.168.0.210","192.168.0.211","192.168.0.212"
$MASK = "255.255.255.0","255.255.255.0","255.255.255.0"
$NIC = "vmnic1","vmnic2","vmnic3"

Set-vMotionMultiNic -VMHost 192.168.0.107 -VirtualSwitch vSwitch1 -pNic $NIC -IPAddress $IP -SubnetMask $MASK

The function creates the vMotion portgroups (in the same way as the VMwareKB video shows).

And each of these vMotion enabled portgroups is configured similar to the method shown in the video.

In a following post I will show how this can be done for a dvSwitch.

Enjoy !

The following script will show,for each cluster node, which FDM role it holds.

function Get-DasHostState{
  param(
  [PSObject]$Cluster
  )

  if($Cluster.GetType().Name -eq "string"){
    $Cluster = Get-Cluster -Name $Cluster
  }
  Get-View -ViewType HostSystem -Property Name,Runtime.DasHostState | %{
    New-Object PSObject -Property @{
      VMHost = $_.Name
      DasHostState = $_.RunTime.DasHostState.State
      StateReporter = (Get-View -Id $_.RunTime.DasHostState.StateReporter -Property Name).Name
    }
  }
}

To call the function you can pass a clustername or the output of a Get-Cluster cmdlet. Something like this.

Get-DasHostState -Cluster Cluster1

or this

$clus = Get-Cluster -Name Cluster1
Get-DasHostState -Cluster $clus

The output looks like this

Note that there are more DasHostState values, besides master and connectedToMaster, possible. The complete list can be found in the ClusterDasFdmAvailabilityState enumeration.

And you can of course provide this functionality as a New-VIProperty.

New-VIProperty -Name "DasHostState" -ObjectType Cluster -Value {
  param($cluster)

  Get-View $cluster.ExtensionData.Host -Property Name,Runtime.DasHostState | %{
    New-Object PSObject -Property @{
      VMHost = $_.Name
      DasHostState = $_.RunTime.DasHostState.State
      StateReporter = (Get-View -Id $_.RunTime.DasHostState.StateReporter).Name
    }
  }
} -Force | Out-Null

Now you can find the FDM states with a call like this

Get-Cluster -Name London | Select -ExpandProperty DasHostState

The output will look exactly the same as the output that comes out of the Get-DasHostState function.

Another HA novelty in vSphere 5 is that it will now use, besides a network-based heartbeat, a datastore heartbeat, to check the presence of the nodes. To find out which of the shared datastores is used as the heartbeat datastore, you can use the following function.

function Get-DasHostState{
  param(
  [PSObject]$Cluster
  )

  if($Cluster.GetType().Name -eq "string"){
    $Cluster = Get-Cluster -Name $Cluster
  }

  $cluster.ExtensionData.RetrieveDasAdvancedRuntimeInfo()  | %{
    $_.HeartbeatDatastoreInfo | %{
      New-Object PSObject -Property @{
        Datastore = (Get-View -Id $_.Datastore).Name
        VMHosts = [string]::Join(',',($_.Hosts | %{(Get-View -Id $_).Name}))
      }
    }
  }
}

The function can be called again with the name of a cluster or with the object returned by the Get-Cluster cmdlet.

Get-DasHostState -Cluster Cluster1

The output looks something like this.

And of course, the same functionality as a New-VIProperty.

New-VIProperty -Name HeartbeatDatastore -ObjectType Cluster -Value {
  param($cluster)

  $cluster.ExtensionData.RetrieveDasAdvancedRuntimeInfo() | %{
    [String]::Join(',',($_.HeartbeatDatastoreInfo |
    %{(Get-View -Id $_.Datastore).Name}))
  }
} -Force | Out-Null

You can now use the HeartbeatDatastore property to get the datastore that is used for the heartbeat.

Get-Cluster -Name Cluster1 | Select Name, HeartbeatDatastore

Which will result in

Enjoy !