Home > Blogs > VMware PowerCLI Blog > Monthly Archives: December 2010

Monthly Archives: December 2010

HA Cluster Improvements

PowerCLI 4.1.1 introduces three new improvements for HA clusters:

  • Ability to edit advanced HA cluster settings
  • Cmdlet that retrieves the primary nodes of HA cluster
  • Set of new properties that contain runtime HA information

The first of the new features is the ability to edit the advanced settings of HA clusters. There are four new cmdlets that allow you to customize HA settings – Get-AdvancedSetting, New-AdvancedSetting, Set-AdvancedSetting, and Remove-AdvancedSetting.

Let’s see several simple actions with these cmdlets:

  • Assign value to isolation address 0 on cluster with name TestCluster
  • Get isolation address 0 for all clusters
  • This command returns all customized settings for a given cluster
  • Update the value of an existing advanced setting for all clusters.
  • Updating can be done also through the New-AdvancedSetting cmdlet and by using the –Force switch. This row adds a value or overrides the already assigned value.
  • Remove a specific customized setting for all clusters.

You can refer to the vSphere Availability Guide for the full list of HA advanced settings.

The second improvement is represented by the Get-HAPrimaryVMHost commandlet. This commandlet returns a list of the primary nodes/hosts for a given cluster and it is really simple to use:

  • Get the primary nodes of a cluster named TestCluster

The third new feature is the addition of new properties in Cluster objects. These properties describe HA cluster runtime information and their names are HATotalSlots, HAUsedSlots, HAAvailableSlots, HASlotCpuMhz, HASlotMemoryMb and HASlotNumVCpus.

For example, let’s see how we can create a report that shows the count of total slots and the count of currently used and available slots.

Improved backward compatibility in PowerCLI 4.1.1

The new PowerCLI 4.1.1 has improved compatibility with scripts written for PowerCLI 4.0.1 and earlier.

PowerCLI 4.1 moved cmdlet output types to new namespaces. This introduced incompatibility with scripts which depend on output types’ full namespace path. To negate the impact of the change and to enable a transition period in which scripts can use full references to both old and new namespaces, PowerCLI 4.1.1 includes additional set of types which reside in the old namespaces (“the old types”) and are implemented by types in the new namespaces.

In practice, this means that code like:
function BackupVM ([VMware.VimAutomation.Types.VirtualMachine] $myVM) { … }
function BackupVM ([VMware.VimAutomation.Client20.VirtualMachineImpl] $myVM) { … }
works with PowerCLI 4.1.1 even though the correct (new) types are:
function BackupVM ([VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine] $myVM) { … }
function BackupVM ([VMware.VimAutomation.ViCore.Impl.V1.Inventory.VirtualMachineImpl] $myVM) { … }

IMPORTANT: The described compatibility support is temporary. We plan to remove the old types in the release following 4.1.1. This means that no new scripts should be written based on the old types and legacy scripts should be updated to remove dependencies on the old types.

As always, it is advisable to avoid full namespace references where possible, and to reference types in the *.Types assemblies instead of their *.Impl counterparts.

Andrey Anastasov,
PowerCLI architect

Enhanced Support for Distributed Switches in PowerCLI 4.1.1

Support for managing distributed switches was initially introduced in PowerCLI 4.1. In PowerCLI 4.1.1,  we extend this functionality by making changes to the following cmdlets:

Returns both standard and distributed switches. You can filter the retrieved switches by their type.
Returns the virtual port groups of the specified standard and distributed switches.
You can retrieve the hosts that are connected to a specific distributed switch.
You can retrieve the virtual machines that are connected to a specific distributed switch.
You can retrieve the host network adapters that are connected to a specific distributed switch.
New-NetworkAdapter, Set-NetworkAdapter
You can attach network adapters to a specific Port Id of the distributed switch.


By using PowerCLI cmdlets, you can migrate virtual machines and hosts between distributed virtual switches, and also create various reports related to distributed switches.


To list all distributed switches available in the vCenter Server, you can just run the Get-VirtualSwitch cmdlet:

The port groups on the distributed switch are also easy to retrieve:

If you need to get the hosts connected to the distributed switch, just filter them by using the Get-VMHost cmdlet:

Even more, you can check which host network adapters are connected to a specific distributed switch:

To check which virtual machines are part of a distributed switch network, use the DistributedSwitch parameter of the Get-VM cmdlet:

Better Firmware management in PowerCLI 4.1.1

The latest release of PowerCLI brings us improvements in managing host firmware for ESXi hosts:

1.    Backup functionality is moved to Get-VMHostFirmware cmdlet and the same is deprecated for Set-VMHostFirmware
2.    You can now backup and restore firmware for more than one host at once. In fact backup will store the host bundles in the specified folder using unique bundle name for each host. Restore will use the bundles from this folder and restore the configuration of the corresponding hosts

Here are some examples:

# Get two hosts to update
$hostList = Get-VMHost -Name <ESXi-hostname1>, <ESXi-hostname2>

# Backup host firmware for the specified hosts
$hostList | Get-VMHostFirmware -BackupConfiguration -DestinationPath C:\StoredBundles

# Put hosts in maintenance mode in order to restore the firmware
$hostList | Set-VMHost -State 'Maintenance'

# Restore firmware for the specified hosts
$hostList | Set-VMHostFirmware -Restore -SourcePath C:\StoredBundles -HostUser root -HostPassword 'pass'

VMHost               UploadUrl
——               ———
<ESXi-hostname1>        http:// <ESXi-hostname1>/tmp/configBundle.tgz
<ESXi-hostname2>        http:// <ESXi-hostname2>/tmp/configBundle.tgz

More details on host firmware functionality are available in the product help or PowerCLI online help.

Support for Virtual Machine SCSI Controllers in PowerCLI 4.1.1

If you’ve ever missed the ability to manage virtual SCSI controllers with PowerCLI, your problem is now solved. The latest PowerCLI release introduces a new group of cmdlets for getting, creating and updating SCSI controllers of virtual machines. You can choose between different SCSI controller types and between different SCSI bus sharing modes. You can also filter the SCSI controllers by several filters: virtual machines, virtual hard disks, templates and snapshots. Here are few examples of usage of the new cmdlets:

Get-VM “VM” | Get-ScsiController
Retrieves the SCSI controllers of the specified virtual machine.

New-ScsiController -HardDisk $hardDisk-Type VirtualBusLogic -BusSharingMode NoSharing
Creates VirtualBusLogic SCSI controller with no sharing support and attaches the specified virtual hard disk to it.

Set-ScsiController -ScsiController $scsicontroller –Type VirtualLsiLogic -BusSharingMode Virtual
Updates an existing SCSI controller’s type and sharing mode.

Besides, you can create a new hard disk by specifying an existing SCSI controller and change the SCSI controller of an existing hard disk. New-HardDisk and Set-HardDisk cmdlets are enhanced with a new “Controller” parameter that accepts objects returned by New\Set\Get-ScsiController cmdlets.

Note that you won’t find a Remove- ScsiController cmdlet. The reason is that you cannot remove a SCSI controller used by at least one virtual hard disk. If a SCSI controller becomes unused by any hard disk, it is automatically removed.

For more details about the support for virtual machine SCSI controllers, check out the PowerCLI cmdlet reference and the online documentation.


ESXCLI now available through PowerCLI

I’ll illustrate esxcli in PowerCLI with an example of how path selection policy can be set for specific storage array type plugin. As you may know, until now this action could be performed by the esxcli command line tool and the call would look something like:

    esxcli nmp satp setdefaultpsp -psp VMW_PSP_RR -satp VMW_SATP_SYMM

From this release the esxcli functionality is available directly through the PowerCLI. The only thing you have to do is to retrieve an EsxCli instance and then invoke any of its methods. So it will look like:

    $esxCli = Get-EsxCli –Server $myEsxConnection

    $esxCli.nmp.satp.setdefaultpsp(“VMW_PSP_RR”, “VMW_SATP_SYMM”)

Note that you have to be connected directly to your ESX, in order to retrieve EsxCli instance (It won’t work with VMHost instances, retrieved from a VC).

In the esxcli tool you have applications, which are grouped in namespaces. Those applications have commands. The same organization is preserved in PowerCLI – The EsxCli object contains the namespaces as properties. The namespace objects contain the applications as properties and finally the commands are methods of those application objects. It’s quite easy to get help for those methods. What you have to do is to call help method for some application object, specifying the name of the desired command method:


You can also retrieve help for the entire application:


Note that this feature is experimental. This means that in future releases backward compatibility is not guarantied.

If you’d like to take a deeper look in the PowerCLI’s esxcli interface, you can read this article: ESXCLI in PowerCLI – overview

Managing vSphere Alarms with PowerCLI

Greetings to all vSphere administrators out there! We are now going to take a look at a new functionality introduced in PowerCLI 4.1 Update 1 – namely vSphere alarms management. We assume that you are already familiar with the vSphere alarms functionality. For those of you who are not, here are some resources on the topic: vSphere Datacenter Administration Guide (see Chapter 13 “Working with Alarms”).

Here’s an excerpt from the VMware documentation – “Alarms are notifications that occur in response to selected events, conditions, and states that occur with objects in the inventory. … The vCenter Server system is configured with a set of predefined alarms that monitor clusters, hosts, datacenters, datastores, networks, and virtual machines.” The current PowerCLI 4.1 Update 1 release supports only modifying the predefined alarms that come with the installation of vCenter Server.

The new cmdlets are:

  • Get-AlarmDefinition
  • Set-AlarmDefinition
  • New-AlarmAction
  • Get-AlarmAction
  • Remove-AlarmAction
  • New-AlarmActionTrigger
  • Get-AlarmActionTrigger
  • Remove-AlarmActionTrigger

With the new cmdlets, you can modify: the alarm actions, the interval on which alarm actions repeat (if repeatable), the alarm names, the alarm descriptions, and whether the alarm is enabled or not. We’ll look at some examples of how we can use these alarm management cmdlets.

Get-AlarmDefinition is a typical PowerCLI getter. It returns all the alarms defined on the vCenter Servers you’re connected to. There are also some optional parameters which allow you to filter the results by name, by the inventory object on which the alarm is defined, and by its state (enabled or disabled).

Here are some examples:

Get-AlarmDefinition # This will return all the defined alarms on the servers you’re connected to

Get-AlarmDefinition -Name "virtual machine*" -Enabled $false # This will return all the disabled alarm definitions with names starting with “virtual machine”

Get-VMHost hostname | Get-AlarmDefinition # This will return all alarms that apply to the host “hostname”. This includes alarms defined on this host and alarms inherited from the parent entity, or from any ancestors in the inventory hierarchy.

Here’s how you can modify an alarm definition:

Get-AlarmDefinition "Host memory status" | Set-AlarmDefinition -Name "Host memory" -Enabled $false # This will rename the alarm to “Host memory” and disable it

The main part of the alarm definitions you can manage is an alarm’s actions configuration. You can create an alarm action this way:

Get-AlarmDefinition "Host storage status" | New-AlarmAction -Email -To “me@mycompany.com” -Subject "Host storage shortage" # This will create a send email action which will be triggered once when the alarm state changes from warning (yellow) to alert (red)

Here is how you can add another action trigger, which will fire earlier – when the alarm state changes from normal (green) to alert (yellow):

$action = Get-AlarmDefinition "Host storage status" | Get-AlarmAction -ActionType SendEmail # Get the action we previously created

$action | New-AlarmActionTrigger -StartStatus Green -EndStatus Yellow –Repeat # Add a new repeating trigger to the action

You can also set the interval at which the action is repeated:

Set-AlarmDefinition "Host storage status" -ActionRepeatMinutes (60 * 24) # This will configure the send email action to repeat once a day (as long as the alarm is in the yellow state)

Finally you may want to remove certain alarm actions. You can do it this way:

$action = Get-AlarmDefinition "Host storage status" | Get-AlarmAction -ActionType SendEmail

Remove-AlarmAction -AlarmAction $action

This is what you can do with the newly introduced cmdlets. The PowerCLI team has decided that the rest of the alarm functionality will not be reconfigured often enough to add cmdlets for the task. However you can always gain full control over the situation through the alarm’s View object. Here’s how you can change alarm configuration that is not available to change through the cmdlets:

# Get the alarm’s view

$alarmDefinition = Get-AlarmDefinition "Host storage status"

$alarmSpecification = $alarmDefinition. ExtensionData

# Make the desired alarm configuration changes

$alarmSpecification. Description="advanced-set description…..”

# Some other changes to the alarm configuration specification (for questions see the vSphere API Reference)

# Update the alarm

$alarmView = Get-View $alarmSpecification.Alarm

$alarmView.ReconfigureAlarm( $alarmSpecification )


Best regards,

-Angel Evrov, MTS at VMware




ESXTOP Available Through PowerCLI

PowerCLI 4.1.1 introduces the new Get-EsxTop cmdlet. This cmdlet provides functionality similar to the “esxtop” utility. The cmdlet allows you to access a wide variety of stats for your virtual environment – thus allowing you to create even more versatile reports using PowerCLI.

There are 3 types of data returned by the cmdlet – counter information, topology information, and statistical data. The counter information shows you the available counters on your ESX as well as their properties (metadata information). To list all available counters you can simply do:

Get-EsxTop –Counter
#  View the fields available for VCPU counter:
(Get-EsxTop –Counter –CounterName VCPU).Fields

The topology information contains either inventory data that does not change (e.g. physical CPU information) or a counter instance structure describing the relationship between different counters. To list all available topologies, run:

Get-EsxTop –TopologyInfo
# View the entries of a specific topology:
(Get-EsxTop –TopologyInfo –Topology SchedGroup).Entries | Format-Table

Finally the statistical data gives you the actual values for the available counters:

# Retrieve the counter values for “VCPU” and “SchedGroup” counters:
Get-EsxTop –CounterName VCPU | Format-Table * -AutoSize
Get-EsxTop –CounterName SchedGroup | Format-Table * -AutoSize

You can use these three sources to navigate the esxtop information and build your reports.

Get-EsxTop works on ESX 4.0 or newer. The cmdlet is dynamic in its nature, meaning that the returned values may differ between ESX versions and the actual data returned is appended as PowerShell dynamic properties to the output objects. Please note that the cmdlet is currently experimental and its output may change in future PowerCLI versions.

PowerCLI 4.1.1 is out

Tonight we released PowerCLI 4.1.1.

Feature Highlights:

  • ESXCLI functionality is now available directly through a new Get-EsxCli cmdlet
  • Esxtop statistics through a Get-EsxTop cmdlet
  • Enhanced vDS support
  • Support for vCenter Server alarms
  • Various host storage enhancements
  • Encrypted credential store

The complete change log is available here.

In the next few weeks we’ll present the most exciting new features with specific posts so stay tuned. In the meantime don’t forget to download and try the new release.