In this blog post, we’ll explore the powerful capabilities of PowerCLI in managing disks within a vSAN cluster and vSAN ESA enabled cluster. Disk management is a critical aspect of maintaining an efficient and optimized virtual storage infrastructure. With the help of specific PowerCLI cmdlets for vSAN cluster, we can manage vSAN disk groups, such as New-VsanDiskGroup, New-VsanDisk, Get-VsanDisk, Remove-VsanDisk, Get-VsanDiskGroup, and Remove-VsanDiskGroup. With Get-VsanEsaEligibleDisk, Add-VsanStoragePoolDisk, Remove-VsanStoragePoolDisk, we can streamline our vSAN ESA storage pool disk management tasks and ensure smooth operations within vSAN or vSAN ESA environment. Let’s dive in!

Managing vSAN Disks Groups and vSAN Disks

In vSAN clusters, vSAN architecture consists of two tiers: a cache tier for the purpose of read caching and write buffering, and a capacity tier for persistent storage. This two-tier design offers supreme performance to VMs while ensuring that data is written to devices in the most efficient way. vSAN uses a logical construct called disk groups to manage the relationship between capacity devices and their cache tier.

Managing vSAN Disk Groups

1. Creating a New Disk Group

To create a new disk group with specific solid-state and hard disk devices, we can use the New-VsanDiskGroup cmdlet. For example, let’s create a new disk group with an SSD and two data disks:

New-VsanDiskGroup -VMHost $vmHost -SsdCanonicalName $MySsdCanonicalName -DataDiskCanonicalName $DataDisk1,$DataDisk2

2. Fetching vSAN Disk Groups

To retrieve information about vSAN disk groups, we can use the Get-VsanDiskGroup cmdlet. For instance, to fetch the disk group “DiskGroup02” we can execute the following command. The output will the type of VsanDiskGroup.

Get-VsanDiskGroup -Name "DiskGroup02"

3. Removing vSAN Disk Groups

If we need to remove a vSAN disk group, we can use the Remove-VsanDiskGroup cmdlet. We can reuse the result from the Get-VsanDiskGroup command.

$diskGroup = Get-VsanDiskGroup -DiskCanonicalName $DiskCanonicalName -VMHost $vmHost
Remove-VsanDiskGroup -VsanDiskGroup $diskGroup -Confirm:$false

vSAN disk groups consist of vSAN disks. We can, therefore,  manage vSAN disks within vSAN disk groups.

4. Adding vSAN Disks to an existing Disk Group

To add a vSAN disk to an existing disk group, we can use the New-VsanDisk cmdlet. For example, we can use the New-VsanDisk cmdlet to add a new disk, “DiskCanonicalName” to this disk group:

New-VsanDisk -CanonicalName "mpx.vmhba0:C0:T11:L0" -VsanDiskGroup $vsanDiskGroup

5. Fetching vSAN Disks

To fetch vSAN disks based on their ID or disk group information, we can use the Get-VsanDisk cmdlet. For instance, to retrieve information about all disks in a specified vSAN disk group we can execute the following command:

Get-VsanDisk -VsanDiskGroup $vsanDiskGroup

6. Removing vSAN Disks from a Disk Group

If we need to remove a vSAN disk from a disk group, the Remove-VsanDisk cmdlet comes to our rescue. Let’s remove “mpx.vmhba0:C0:T11:L0” disk by using the following command:

$vsanDisk = Get-VsanDisk -CanonicalName "mpx.vmhba0:C0:T11:L0"
Remove-VsanDisk -VsanDisk $vsanDisk -Confirm:$false

Introducing Storage Pool Disks in vSAN ESA

In the vSAN 8.0, we introduced a new storage architecture. In vSAN ESA (Express Storage Architecture), we introduced a new storage format called storage pool disks. These disks provide a more efficient and simplified approach to adding, removing, and managing storage within the ESA environment.

We can claim disks to define a storage pool on a vSAN host. Each host that contributes storage contains a single storage pool of flash devices. Each flash device provides caching and capacity to the cluster. We can create a storage pool with any devices that are compatible for ESA. vSAN creates only one storage pool per host.

In a storage pool, each device provides both caching and capacity in a single tier. This is different from a Disk Group, which has dedicated devices in different tiers of cache and capacity.

Before we add storage pool disks, we can see which one is available to add by using the Get-VsanEsaEligibleDisk cmdlet. The output will be the ScsiLun type.

Get-VsanEsaEligibleDisk -Cluster $cluster

When we know the disk canonical name from ScsiLun, we can claim disks to define the storage pool on a specified host.

Add-VsanStoragePoolDisk -VMHost (Get-VMHost "MyVMHost") -VsanStoragePoolDiskType "singleTier" -DiskCanonicalName ("mpx.vmhba0:C0:T11:L0","mpx.vmhba0:C0:T12:L0")

Also, we can query the storage pool disk with the specified VMHost or Cluster, and remove the disk from the defined storage pool disk.

$disks =get-vsanstoragepooldisk -VMHost (Get-VMHost 10.192.201.50)

Remove-VsanStoragePoolDisk -VsanStoragePoolDisk $disks -VsanDataMigrationMode nodatamigration -Purpose "test" -Confirm:$false

By harnessing the power of PowerCLI and leveraging its rich features, you can simplify and optimize your storage infrastructure, ensuring smooth operations within your vSAN cluster.

Happy disk management with PowerCLI in your vSAN environment!

In the ever-evolving world of PowerCLI, each release brings exciting updates and enhancements to vSAN. With new cmdlets and vSAN APIs, managing your virtual storage infrastructure becomes even more efficient and powerful. One of the recent additions to PowerCLI is the support for remote datastore related features, opening up new possibilities for vSAN clusters.

Now, vSAN clusters have the ability to share their datastores with other vSAN clusters, or even beyond a single vCenter Server. The beauty of this functionality lies in the flexibility it offers. Any compatible vSAN cluster can act as a server, allowing other vSAN clusters to mount its local datastores. This opens up a world of potential use cases and enables efficient data sharing across clusters.

But how do you go about mounting a remote datastore using PowerCLI? Fear not, as I’ll guide you through the process using PowerCLI cmdlets in various scenarios.

Managing vSAN Remote Datastores

Starting from PowerCL 12.7, we have introduced support for querying, mounting, and unmounting remote datastores for a specific cluster using the Get-VsanClusterConfiguration and Set-VsanClusterConfiguration cmdlets. Let’s delve into the details and discover how these cmdlets can empower you in managing remote datastores.

Query the mounted remote datastores

By utilizing the Get-VsanClusterConfiguration cmdlet, we gain access to view all the properties of the vSAN configuration within the specific cluster. This includes crucial information about the mounted remote datastores.

In addition to accessing the overall vSAN configuration, we can specifically retrieve the value of the RemoteDatastore property by using a simple dot notation. This allows us to obtain accurate details about the remote datastores and their current status.

Get-VsanClusterConfiguration -Cluster "MyCluster" | select *
$vsanConfiguration = Get-VsanClusterConfiguration -Cluster "MyCluster"
$vsanConfiguration.RemoteDatastore

Mount / Unmount the remote datastore

As we intend to modify the vSAN configuration setting, we will utilize the Set-VsanClusterConfiguration cmdlet. To do so, it is necessary to retrieve the original vSAN cluster configuration beforehand with the Get-VsanClusterConfiguration cmdlet.

$config = Get-VsanClusterConfiguration -Cluster "MyCluster"
Set-VsanClusterConfiguration -Configuration $config -MountRemoteDatastore (Get-Datastore -Name "MyDatastore")

#If we want to unmount the existing remote datastore, we can go fetch the current vSAN configuration again
$newVsanConfiguration = Get-VsanClusterConfiguration -Cluster "MyCluster"
Set-VsanClusterConfiguration -Configuration $newVsanConfiguration -UnMountRemoteDatastore $newVsanConfiguration.RemoteDatastore

Mount / Unmount the remote datastore from the stretched cluster

In the latest PowerCLI 13.1 release, which supports vSAN 8.0 Update 1, we’re thrilled to introduce the ability to mount remote datastores from both stretched clusters and vSAN ESA (Express Storage Architecture) enabled clusters. If you want to mount or unmount the remote datastore from a vSAN ESA enabled cluster, the operation would be the same as the first scenario, the normal vSAN cluster, and no additional settings are required. Let’s take a look at the configuration steps involved when mounting from stretched clusters

Mounting the Remote Datastore from Stretched Clusters

When dealing with stretched clusters, an additional configuration step is necessary to ensure seamless remote datastore mounting. Specifically, you’ll need to configure the RemoteVsanServerClusterConfig as outlined below.

Understanding the NetworkTopology Parameter

The NetworkTopology parameter plays a crucial role in defining the network topology between the client and server clusters in an HCI Mesh configuration. It offers two values: Asymmetric and Symmetric. In a Symmetric configuration, no ServerSiteName or ClientSiteName is required. However, in an Asymmetric configuration, the ServerSiteName becomes necessary and represents the fault domain of the stretched cluster, which is referred to as “Preferred” or “Secondary”. Additionally, if both the host cluster and server cluster are stretched clusters, the ClientSiteName is also required.

Below are some sample configurations for different RemoteVsanServerClusterConfig scenarios.

$serverconfig = New-RemoteVsanServerClusterConfig -cluster $clusterServer -networktopology "Symmetric" 
$serverconfig = New-RemoteVsanServerClusterConfig -cluster $clusterServer -networktopology "Asymmetric" -ServerSiteName "Secondary"
$serverconfig = New-RemoteVsanServerClusterConfig -cluster $clusterServer -networktopology "Asymmetric" -ServerSiteName "Secondary" -ClientSiteName "Preferred"

Set-VsanClusterConfiguration -configuration $clusterClient -MountRemoteDatastore $datastore -RemoteVsanServerClusterConfig $serverconfig

When unmounting a remote datastore from the stretched cluster, it is enough to pass the UnmountRemoteDatastore parameter. The RemoteVsanServerClusterConfig will be automatically adjusted and cleared accordingly.

Set-VsanClusterConfiguration -configuration $config -UnmountRemoteDatastore $datastore

Mount / Unmount the remote datastore from another vCenter Server system

In PowerCLI13.1, we also have the capability to mount and unmount remote datastores from another vCenter Server System, allowing for cross-vCenter remote datastore operations.

Adding Datastore Source to the current vCenter Server system

Before we can proceed with mounting the Cross-vCenter (XVC) remote datastore, we need to add the datastore source to the current vCenter Server system by using the appropriate credentials. This step ensures that the target vCenter Server can be accessed as another datastore source. To achieve this, we can utilize the New-VsanHCIMeshDatastoreSource cmdlet, where the VCHost parameter specifies the target vCenter that we want to add as a datastore source.

New-VsanHCIMeshDatastoreSource -VCHost 'MyAnotherVCIP' -User 'administrator@vsphere.local'  -Password 'MyVCPassword'

Retrieving HCI Mesh Datastore

Once we’ve successfully added the datastore source, we can retrieve the datastore and fetch the HCI mesh datastore from the specified source. This retrieval process allows us to access the necessary data and information required for further operations.

$dsSource = Get-VsanHCIMeshDatastoreSource -VCHost 'MyVCIP'
$ds = Get-VsanHCIMeshDatastore -VsanHCIMeshDatastoresource $dsSource

Mounting and Unmounting Remote Datastores

With the retrieved HCI mesh datastore at our disposal, we can now proceed to mount or unmount the remote datastore by using the MountXVCDatastore or UnmountXVCDatastore parameters. With these parameters, you can execute the desired operations efficiently.

Set-VsanClusterConfiguration -Configuration $clusterClient -MountXVCDatastore $ds

Set-VsanClusterConfiguration -Configuration $clusterClient -UnmountXVCDatastore $ds

Query the mounted datastore from another vCenter Server System

The mounted datastore from another vCenter Server system can be fetched with the VsanXVCDatastore parameter.

$vsanConfiguration = Get-VsanClusterConfiguration -Cluster "MyCluster"

$vsanConfiguration.VsanXVCDatastore

#output
DatastoreMoID            OwnerVcAddress
----------------------   --------------
Datastore-datastore-17   MyVCIP

Summary

In this blog post, we’ve touched upon the latest advancements in PowerCLI and vSAN, focusing on the ability to mount remote datastores. As we move forward, we’ll delve deeper into each scenario and provide step-by-step guides on configuring remote datastores for stretched clusters, understanding network topology, implementing the RemoteVsanServerClusterConfig cmdlet, and exploring the cross-vCenter remote datastores.

Join us on this thrilling journey as we unlock the full potential of PowerCLI and vSAN, empowering you to optimize your virtual storage infrastructure and harness the benefits of remote datastore mounting. Exciting times lie ahead for vSAN enthusiasts and PowerCLI users alike!

Make sure to stay tuned for our upcoming blog posts as we’ll unveil more insights, tips, and tricks to enhance your vSAN management experience. Until then, happy exploring!

This blog post explains how to configure Array Based Replication (ABR) with the PowerCLI VMware.Sdk.Srm module. Before diving in, consider reading the blog post, explaining the basic concepts of the VMware.Sdk.Srm module: “Managing SRM and VR with PowerCLI 13.1“. There you can find out more about the module’s connection management, which will not be covered in details here.

Connect Site Recovery Manager with Connect-SrmSdkServer

To connect Site Recover Manager server use the Connect-SrmSdkServer cmdlet:

$srmConnection = Connect-SrmSdkServer -Server "MySrmAddress.com" `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVcPassword" `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVcPassword"

Create Array Managers for the Array Pair

Before creating the array pair you must create array managers for the local and the remote sites.

Retrieve Storage Replication Adapter for the local Array Manager

For this example we will use NetApp Storage Replication Adapter for ONTAP:

$localAdapter = (Invoke-SrmGetStorageAdapters -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -FilterProperty 'Name' `
   -Filter 'NetApp').List[0]

Invoke-SrmGetStorageAdapters returns a list of adapters, matching the specified filters. In our case we filter the available storage adapters by their Name property and expect only one adapter with name matching ‘NetApp’ to be found. Accordingly we will use the first element of the List property of the StorageAdapterDetailsDrResponseList object, returned from Invoke-SrmGetStorageAdapters.

Prepare Connection Parameters for the Storage Replication Adapter

To allow the array manager to communicate with the storage adapter we must prepare connection parameters, which will be used for the connection. Retrieve ConnectionParamGroup object for the local storage adapter:

$localConnectionParamGroup = (Invoke-SrmGetStorageAdapterConnectionParams `
   -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -StorageAdapterId $localAdapter.Id).List[0]

The output of Invoke-SrmGetStorageAdapterConnectionParams is a ConnectionParamGroupDrResponseList object, which in our case contains a list of one ConnectionParamGroup element. You have to provide values to the connection parameter, available in the $localConnectionParamGroup.ConnectionParams list. The set of parameters, available in the ConnectionParams list is specific for the used storage replication adapter. Here we will provide values for connection parameters, specific for the NetApp storage replication adapter:

($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "username"}).Value = "myUser"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "password"}).Value = "myPass"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "VolumeInclusion"}).Value = "myVolume"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "SVM Name"}).Value = "myLocalSvmName"
($localConnectionParamGroup.ConnectionParams | where {$_.key -eq "mgmtIP"}).Value = "192.168.10.10"

Create the local Array Manager

Now when we have all the prerequisites for the array manager, use the ConnectionParamGroup and the storage adapter Id to initialize ArrayManagerSpec object:

$localArrayManagerSpec = Initialize-SrmArrayManagerSpec -Name "primary-array-manager" `
   -StorageAdapter $localAdapters.Id `
   -ConnectionParams $localConnectionParamGroup

Then create the array manger, using the Invoke-SrmCreateArrayManage cmdlet:

$task = Invoke-SrmCreateArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -ArrayManagerSpec $localArrayManagerSpec

Wait for the task to complete and retrieve the array manager. The Result property of the task will contain the Id of the array manager, once the task completes:

$localManagerTask = Invoke-SrmGetTaskInfo -TaskId $task.Id

$localArrayManager = Invoke-SrmGetArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -ArrayManagerId $localManagerTask.Result

Create the remote array manager, using the same approach:

$remoteAdapter = (Invoke-SrmGetStorageAdapters -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id.Guid `
   -FilterProperty 'Name' `
   -Filter 'NetApp').List[0]

$remoteConnectionParamGroup = (Invoke-SrmGetStorageAdapterConnectionParams `
   -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id.Guid `
   -StorageAdapterId $remoteAdapters.List[0].Id).List[0]

($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "username"}).Value = "myUser"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "password"}).Value = "myPass"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "VolumeInclusion"}).Value = "myVolume"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "SVM Name"}).Value = "myRemoteSvmName"
($remoteConnectionParamGroup.ConnectionParams | Where-Object {$_.key -eq "mgmtIP"}).Value = "192.168.10.11"

$remoteArrayManagerSpec = Initialize-SrmArrayManagerSpec -Name "secondary-array-manager" `
   -StorageAdapter $remoteAdapter.Id `
   -ConnectionParams $remoteConnectionParamGroup

$task = Invoke-SrmCreateArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id.Guid `
   -ArrayManagerSpec $remoteArrayManagerSpec

#Wait for the create array manager task to complete
$remoteManagerTask = Invoke-SrmGetTaskInfo -TaskId $task.Id

$remoteArrayManager = Invoke-SrmGetArrayManager -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.RemoteSrmServer.Id.Guid `
   -ArrayManagerId $remoteManagerTask.Result

Create Replicated Array Pair

To create the replicated array pair, you have to initialize a ReplicatedArrayPairSpec object:

$replicatedArrayPairSpec = Initialize-SrmReplicatedArrayPairSpec -ArrayManagerId $localArrayManager.Id `
   -StorageArrayKey $localArrayManager.StorageArrays[0].StorageArrayKey `
   -PeerStorageArrayKey $remoteArrayManager.StorageArrays[0].StorageArrayKey

Besides the ArrayManagerId you have to specify the StorageArrayKey and the PeerStorageArrayKey parameter. The available storage array keys can be found in the StorageArrays property of the local and the remote array managers.

Use the Invoke-SrmCreateReplicatedArrayPair cmdlet to create the replicated array pair:

$task = Invoke-SrmCreateReplicatedArrayPair -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -ReplicatedArrayPairSpec $replicatedArrayPairSpec

Wait for the task to complete and retrieve the replicated array pair. The Result property of the task will contain the Id of the replicated array pair, once the task completes:

$replicatedArrayPairTask = Invoke-SrmGetTaskInfo -TaskId $task.Id

$replicatedArrayPair = Invoke-SrmGetReplicatedArrayPair -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -ArrayPairId $replicatedArrayPairTask.Result

Create Protected Group and Recovery Plan for the Replicated Array Pair

Use the Invoke-SrmDiscoverStorageDevices cmdlet to discover the storage devices of the replicated array pair. Wait for the task to complete before proceeding to the next step:

$task = Invoke-SrmDiscoverStorageDevices -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -ArrayPairId $replicatedArrayPair.Id

Invoke-SrmGetTaskInfo -TaskId $task.Id

Retrieve the storage devices from the replicated array pair:

$storageDevices = Invoke-SrmGetStorageDevices -PairingId $srmConnection.ConnectedPairing.PairingId `
   -SrmId $srmConnection.ConnectedPairing.LocalSrmServer.Id.Guid `
   -ArrayPairId $replicatedArrayPair.Id

Initialize an AbrProtectionGroupSpec object. In our setup we created replicated array pair with single storage device, containing one datastore. We will create protection group for this datastore:

$abrProtectionGroupSpec = Initialize-SrmAbrProtectionGroupSpec `
   -ReplicatedArrayPair $replicatedArrayPair.Id `
   -Datastores $storageDevices.StorageDevicesData[0].Datastores[0].Id

Then initialize ProtectionGroupCreateSpec object. For the ReplicationType parameter specify ABR:

$protectionGroupSpec = Initialize-SrmProtectionGroupCreateSpec -Name "MyAbrProtectionGroup" `
   -ReplicationType ABR `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -AbrSpec $abrProtectionGroupSpec

Use Invoke-SrmCreateGroup to create the ABR protection group. Wait for the task to complete and retrieve the protection group:

$task = Invoke-SrmCreateGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -ProtectionGroupCreateSpec $protectionGroupSpec

$task = Invoke-SrmGetTaskInfo -TaskId $task.Id

$protectionGroup = Invoke-SrmGetGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -GroupId $task.Result

Finally, you can create recovery plan for the protection group, we have just crated. To do this, Initialize RecoveryPlanCreateSpec object:

$recPlanSpec = Initialize-SrmRecoveryPlanCreateSpec `
   -Name "AbrRecoveryPlan" `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -ProtectionGroups @($protectionGroup.Id)

Create recovery plan with the Invoke-SrmCreatePlan cmdlet and wait for the task to complete:

$task = Invoke-SrmCreatePlan -PairingId $srmConnection.ConnectedPairing.PairingId `  
   -RecoveryPlanCreateSpec $recPlanSpec

Invoke-SrmGetTaskInfo -TaskId $task.Id

Disconnect the SRM server connection

After you have finished interacting with the SRM server, close the connection, using the Disconnect-SrmSdkServer cmdlet.

Disconnect-SrmSdkServer "MySrmAddress.com"

Conclusion

VMware.Sdk.Srm PowerCLI module enables the access to the Site Recovery Manager Rest API through PowerShell cmdlets. In this article we covered the end to end scenario of configuring array based replication and creation of protection group and recovery plan, based on this replication flavor. If you’re interested in using host based replication, refer to the “Managing SRM and VR with PowerCLI 13.1” blog post.

PowerCLI 13.1 introduces two new auto generated modules that provide PowerShelI bindings for the vSphere Replication REST API and the Site Recovery Manager REST API. We will cover connection management for both modules – host based replication with vSphere Replication and creation of protection groups and recovery plans with Site Recovery Manager.

Note: VMware.Sdk.Vr and VMware.Sdk.Srm modules are compatible with vSphere Replication and Site Recovery Manager 8.7 and above.

Connecting vSphere Replication server with Connect-VrServer

To connect to a vSphere Replication management server you must use the Connect-VrServer cmdlet. Replications can be configured within a single vCenter Server, or between local and remote vCenter Server instances.

When configuring replication within the same VC you can connect only to the local vSphere Replication site. For Server parameter specify the vSphere Replication server address. For User and Password parameters specify the user name and the password for the vCenter Server instance where the vSphere Replication appliance is deployed:

$vrConnection = Connect-VrServer -Server "MyVrAddress.com" 
   -User "administrator@vsphere.local" `
   -Password "MyLocalVCenterServerPassword"

Let’s take a moment and look at the VrServerConnection object, returned from the Connect-VrServer cmdlet. It contains ConnectedPairings property:

This property is a Dictionary, where all connected Pairings are stored. The Pairing is the VR API representation of the paired local and the remote sites. As we just authenticated only against the local VR site, the Dictionary contains only one entry. This is the local vCenter self-pair.

You can index this dictionary, by the vCenter name, and obtain certain Pairing object. You will need this Pairing object to invoke various operations from the VR API:

To authenticate against a remote vCenter Server, you will use another parameter set of the Connect-VrServer cmdlet. (Note that you must have a site pairing configured between the local and the remote vSphere Replication sites.). This time, for LocalServer parameter specify the already available VrServerConnection object. For RemoteServer parameter specify the name of the remote VC. For RemoteUser and RemotePassword parameters specify the user name and the password of the remote VC. Note that with VR we can have multiple remote sites configured:

$remoteVc = "myRemoteVcName"
$vrConnection = Connect-VrServer -LocalServer $vrConnection `
    -RemoteServer $remoteVc `
    -RemoteUser "administrator@vsphere.local" `
    -RemotePassword "MyRemoteVCenterServerPassword"

Now, if you check the ConnectedPairings property of the VrServerConnection object, you will see that the dictionary contains second pairing, allowing you to invoke API operations on the remote site:

Alternatively you can authenticate against the local and the remote sites with a single Connect-VrServer call:

$remoteVc = "myRemoteVcName"
$vrConnection = Connect-VrServer -Server $localVr `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVCenterServerPassword" `
   -RemoteServer $remoteVc `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVCenterServerPassword"

Configuring host based replication

For convenience, let’s store the remote site pairing that we will use for the replication in a variable:

$remotePairing = $vrConnection.ConnectedPairings[$remoteVc].Pairing

Retrieve the replicated VM

To start, you must retrieve the VM, which you want to replicate. Use the Invoke-VrGetLocalVms cmdlet, which requires PairingId and VcenterId parameters to be specified. We have these IDs with the Pairing object we stored in the $remotePairing variable:

$replicatedVm = Invoke-VrGetLocalVms -PairingId $remotePairing.PairingId `
   -VcenterId $remotePairing.LocalVcServer.Id.Guid `
   -FilterProperty 'Name' `
   -Filter "VrSrmDemo"

You can also apply filter to this call. FilterProperty parameter specifies the VM property that will be used for the search. In this case this is the Name property. The Filter parameter specifies the property value, you are looking for. The result of this call is a VirtualMachineDrResponseList object, which contains list of VMs that match the specified filter. In our case this will be a list with one VM:

Configure VM’s HDDs for the replication

When configuring host based replication, you have to specify the VM’s hard disks that will be replicated. For each replicated disk you have to specify a datastore on the target VC. In this example we will replicate all the hard disks of our VM on one target datastore on the remote VC:
Retrieve the target datastore on the remote VC, using the Invoke-VrGetVrCapableTargetDatastores cmdlet:

$targetDatastore = Invoke-VrGetVrCapableTargetDatastores -PairingId $remotePairing.PairingId `
   -VcenterId $remotePairing.RemoteVcServer.Id.Guid `
   -FilterProperty "Name" `
   -Filter "MyRemoteDS"

Here for VcenterId, specify the remote VC Id. Specify FilterProperty and Filter parameters to choose the target datastore by name.

Hard disks are available in the Disks property of our VirtualMachine object, stored in the $replicatedVm variable. Iterate over the Disks list and initialize ConfigureReplicationVmDisk objects for each hard disk. Store these configurations in $replicationVmDisks array variable:

$replicationVmDisks = @()
$replicatedVm.List[0].Disks | ForEach-Object {
   $replicationVmDisks += Initialize-VrConfigureReplicationVmDisk -VmDisk $_ `
      -EnabledForReplication:$true `
      -DestinationDatastoreId $targetDatastore.List[0].Id `
      -DestinationDiskFormat 'SAMEASSOURCE'
}

Configure Host Based Replication

First you have to initialize ConfigureReplicationSpec object. Besides various replication settings, we have to specify the disk replication configuration, stored in the $replicationVmDisks variable to the Disk parameter. You also have to specify the target VC Id and the Id of the replicated VM.

$replicationSpec = Initialize-VrConfigureReplicationSpec `
   -Rpo 60 `
   -NetworkCompressionEnabled:$true `
   -MpitEnabled:$true `
   -AutoReplicateNewDisks:$true `
   -LwdEncryptionEnabled:$false `
   -MpitInstances 1 `
   -MpitDays 1 `
   -Disks $replicationVmDisks `
   -TargetVcId $remotePairing.RemoteVcServer.Id.Guid `
   -VmId $replicatedVm.List[0].Id

Then use the Invoke-VrConfigureReplication cmdlet to configure the replication. For parameters, specify the PairingId and the ConfigureReplicationSpec object:

$task = Invoke-VrConfigureReplication -PairingId $remotePairing.PairingId `
   -ConfigureReplicationSpec $replicationSpec

The result of the operation is a TaskDrResponseList object, which in our example contains list of one task. If you want, you can specify array of ConfigureReplicationSpec objects, and replicate multiple VMs with single call.

To wait until the replication configuration task completes, retrieve the task until its Status property equals to something different from ‘RUNNING’:

Invoke-VrGetTaskInfo -TaskId $task.List[0].Id

In the next chapter we will use cmdlets from the VMware.Sdk.Srm module to create protection group and recovery plan for the replication that we just created.

Connecting Site Recovery Manager with Connect-SrmSdkServer

To connect Site Recover Manager server use the Connect-SrmSdkServer cmdlet. Do not use the old Connect-SrmServer cmdlet, already available in the VMware.VimAutomation.Srm module, as it’s not compatible with the VMware.Sdk.Srm module cmdlets.

Site Recover Manager supports only one pairing between local and remote SRM sites. You can connect either only to the local site, or you can authenticate with the remote site vCenter server site in the same call. Since we will further create protection group and recovery plan we will choose the second option. Note that you must have a site pairing configured between the local and the remote SRM sites.

$srmConnection = Connect-SrmSdkServer -Server "MySrmAddress.com" `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVcPassword" `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVcPassword"

If we look at the SrmServerConnection object, returned from the Connect-SrmSdkServer cmdlet, we will see that it contains property named ConnectedPairing. In this case this is a single Pairing object that represents the pair between the local and the remote SRM sites. You will need this Pairing object for invoking various operations from the SRM API:

Creating protection group and recovery plan for host based replication

In this chapter we will use the host based replication that we configured earlier. First we will initialize HbrProtectionGroupSpec with the VM that we already replicated:

$hbrSpec = Initialize-SrmHbrProtectionGroupSpec -Vms $replicatedVm.List[0].Id

In this example we reuse the VM Id, we have stored in the $replicatedVm variable, as it’s consistent between the VR and SRM APIs. If you need to retrive the replicated VM with the VMware.Sdk.Srm module, use the Invoke-SrmGetReplicatedVms cmdlet:

$replicatedVm = Invoke-SrmGetReplicatedVms `
   -PairingId $srmConnection.ConnectedPairing.PairingId `
   -VcenterId $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -FilterProperty "Name" `
   -Filter "VrSrmDemo"

Use the HbrProtectionGroupSpec object to initialize SrmProtectionGroupCreateSpec. For the ReplicationType parameter specify HBR:

$protectionGroupSpec = Initialize-SrmProtectionGroupCreateSpec -Name "SrmDemoGroup" `
   -ReplicationType HBR `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -HbrSpec $hbrSpec

Create protection group with the Invoke-SrmCreateGroup cmdlet:

$task = Invoke-SrmCreateGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -ProtectionGroupCreateSpec $protectionGroupSpec

Wait for the SRM task to complete:

$task = Invoke-SrmGetTaskInfo -TaskId $task.Id

When $task.Status is equal to ‘SUCCESS’, retrieve the protection group, using the $task.Result property, which contains the ID of the created group:

$protectionGroup = Invoke-SrmGetGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -GroupId $task.Result

To conclude this example we will create a recovery plan for the protection group. For that purpose first Initialize RecoveryPlanCreateSpec, required by the Invoke-SrmCreatePlan cmdlet:

$recPlanSpec = Initialize-SrmRecoveryPlanCreateSpec `
   -Name "SrmDemoRecoveryPlan" `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -ProtectionGroups $protectionGroup.Id

Then create the recovery plan with the RecoveryPlanCreateSpec object and wait for the task to complere, using the Invoke-SrmCreatePlan:

$task = Invoke-SrmCreatePlan -PairingId $srmConnection.ConnectedPairing.PairingId `
  -RecoveryPlanCreateSpec $recPlanSpec
Invoke-SrmGetTaskInfo -TaskId $task.Id

Disconnect SRM and VR server connections

After you have finished interacting with the SRM server, close the connection, using the Disconnect-SrmSdkServer cmdlet:

Disconnect-SrmSdkServer "MySrmAddress.com"

To close the VR server connection use the Disconnect-VrServer cmdlet:

Disconnect-VrServer "MyVrAddress.com"

Conclusion

You can combine the VMware.Sdk.Vr and the VMware.Sdk.Srm PowerCLI modules to automate the end to end scenario of creating host based replication, and utilizing it with protection group and recovery plan. If you want to automate array based replication, available with the VMware.Sdk.Srm module, refer to the “Array Based Replication with PowerCLI 13.1” blog post. Also, you can check out “vSphere Replication REST API with PowerShell: Configure VM replication“.

After the exciting first release of Power Actions last week, this week brings another new release – PowerCLI 13.1.

With this release, we’re delivering one of the most requested PowerCLI features – a PowerCLI module for vSphere Replication. It is built on the same technology that we used to deliver the auto-generated modules for the NSX and vSphere REST APIs and provides full coverage of the new vSphere Replication REST API.

Here are some of the other exciting features of this PowerCLI release:

• New auto-generated module for the new SRM REST API
• Added support for vLCM host configuration and offline depots
• New vSAN cmdlets for vSAN direct disk and remote datastore management
• New cmdlets for vSAN cluster shutdown
• Updated NSX and Horizon modules
• Extended Python version support for the ImageBuilder module

Let’s take a closer look at some of these new features.

New SDK modules for SRM and vSphere Replication

With the 8.6 release of SRM and vSphere Replication, these two products received new REST APIs. In fact, it was the first public API released for vSphere Replication. This gave us the opportunity to automatically generate PowerCLI modules for these products as we had already done for NSX and vSphere. As with vSphere you will be able to find the PowerCLI examples directly in the vSphere Replication and SRM REST API documentation. We’re also working on a dedicated blog post to demonstrate how to use those modules to perform some common use cases.

vLCM improvements

In PowerCLI 13.1 we’re adding new parameters to the Set-VMHost cmdlet to allow you to set the ESXi host LCM configuraiton in the same way that you set the cluster LCM configuration. This is a new feature, supported only in vSphere 8.0 Update 1. We’re also introducing cmdlets for the creation of new LCM offline depots with PowerCLI.

New vSAN cmdlets

PowerCLI 13.1 comes with a lot of new vSAN functionality. New cmdlets are introduced for vSAN remote datastore management, direct disk management, and vSAN cluster shutdown.

VMware Cloud Director changes

For VMware Cloud Director, we changed the authentication mechanism of Connect-CIServer and it now authenticates against the new vCD API authentication endpoint. This will allow the cmdlet to continue working without issues with the future vCD versions. We also updated the Import-CIVappTemplate cmdlet to work with the latest APIs. Because of this we made some cmdlet interface changes, which might lead to the need of reworking some of your Cloud Director scripts.

ImageBuilder module Python version support

With PowerCLI 13.0 we ported the ImageBuilder and AutoDeploy modules to work on Linux and MacOS. That required users to have Python installed as a pre-requisite for those modules. In 13.0, these modules only supported Python version 3.7.x, which was quite limiting. With PowerCLI 13.1, we have fixed that and the ImageBuilder module now works with Python 3.7.1 and all later versions.

Conclusion

PowerCLI 13.1 is another release that brings a rich set of new features to our customers. It delivers one of the most requested PowerCLI functionalities, vSphere replication module, as well as new SRM module, new vSAN cmdlets, extended support for vLCM, and much more. For a full list of all improvements and fixes, check the PowerCLI 13.1 Release Notes. For more information on specific cmdlets, see the PowerCLI Cmdlet Reference.

We are extremely excited to announce that the first standalone tech preview release of the new Power Actions went live today.

Power Actions is a vSphere Client plug-in that provides an easy way to share PowerCLI scripts with users who have no PowerShell experience. Power Actions provides a script library where you can upload PowerCLI scripts that you want to make available to everyone in your organization. Users can then easily execute those scripts using a user-friendly interface to specify the script parameters. This provides an extremely powerful mechanism to extend the vSphere Client with custom PowerCLI scripts.

How about the security and permissions? All the scripts are executed by using the permissions of the user that’s logged in to the vSphere Client. So, if a user does not have permission to perform certain operations they won’t be able to perform these operations with Power Actions as well.

Let’s take a closer look at how to get started with Power Actions:

Installation

Power Actions is distributed as a virtual appliance. You can download the OVA file from the Power Actions page. Also from there, you can download the complete user’s guide that contains detailed installation instructions. After you install Power Actions you can use it through the Developer Center in the vSphere Client.

Script library

The main function of Power Actions is to run scripts from your script library. So the first thing to do is to create a script library and upload your scripts there.

Script libraries are actually content libraries, so any content library can be used as a script library. If you don’t have a content library at your disposal, you can create a new one by using either PowerCLI or the vSphere Client. The next step is to import your scripts to the script library. You can upload scripts one by one through the vSphere Client, or entire collections of scripts through PowerCLI.

Running scripts

Once you have uploaded your scripts to the script library, you can start running them. You have two options to run a script – from the script library directly or through the context menu. In both cases, when you execute a script with parameters, you’ll be prompted to enter them. However, when you run a script from the context menu, some parameters will be pre-populated.

Let’s take a closer look at how this works. In our Power Actions script library we have imported a simple PowerCLI script that creates snapshots of a collection of virtual machines. This is what the script looks like:

param (
    [Parameter(Mandatory=$true)]
    [VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine[]] $vms, 
    [Parameter(Mandatory=$true)]
    [string] $snapshotName)

foreach ($vm in $vms) {
    New-SnapShot -VM $vm -Name $snapshotName
}

When we run this script from the script library, we’ll get a dialog in which we’ll have to specify the script parameters.

However, if we want to run the script from the context menu, we can right-click on a VM and select “Power Actions” -> “Run script”.

We’ll get a dialog to first select the script that we want to run, and then we’ll have to enter the parameters. In this case, the vms parameter will be pre-populated from the VM we right-clicked on.

Monitoring script runs and checking the results

The next screen in Power Actions is ‘Script runs’. There you can monitor your script runs and check their result. From this page you can also stop a running script.

Console

Another feature Power Actions provides is a built-in PowerShell console with the latest PowerCLI version pre-installed. When you open the console, it automatically connects to the vCenter Server by using the vSphere Client user. You can use the Power Actions console to run single commands or entire scripts. Keep in mind that the console will not be retained when you log out of the vSphere Client, so any files that you save on it will be lost after you log out. Beware that if you switch to another view in the vSphere Client or to another Power Actions screeen, and then return to the console, a new PowerShell session will be created and all in-memory variables from your previous session will be lost.

Summary

Throughout the years, Power Actions underwent multiple transformations and was part of different fling releases of the vSphere Client. Now we’re starting to develop it again as an independent product and this first tech preview release of the new Power Actions is the first step of the process. We are very excited about the plethora of possibilities that Power Actions brings and we can’t wait to receive your feedback, use cases, feature requests and ideas. So don’t hesitate to submit your comments on the Power Actions site.

Many customers use the PowerCLI credential store to avoid hard coding credentials in scripts or saving them unencrypted in files. The credential store uses the Windows data protection API to encrypt the credentials and then saves them in a file. However, this API is only available in Windows and that’s why the PowerCLI credential store is not available on the cross-platform PowerShell 7. So what is the alternative for Linux and MacOS users?

Some time ago, Microsoft released two very useful cross-platform modules for managing secrets – SecretManagement and SecretStore. You can read more details about them in this blog post. SecretManagement provides cmdlets that help users manage secrets across different vaults and SecretStore is one vault implementation. These two modules can be used instead of the VICredential store. To illustrate how this can be done, we’ve built a sample module with alternative versions of the VICredential store cmdlets using the two Microsoft modules. You can use this module as it is or just as a reference to build your own solution. Let’s go over the main use cases.

Secret store configuration and vault registration

The first step is to register and configure the secret vault. In our sample module, we have added an Initialize-VISecret cmdlet that does this. It registers SecretStore as a default vault and configures it to not prompt for a password when accessing the vault.

function Initialize-VISecret {
    [CmdletBinding()]
    param(
        [string]$Vault = "VMwareSecretStore"
    )

    process {
         Set-SecretStoreConfiguration -Scope CurrentUser -Authentication None -Interaction None -Confirm:$false 
         Register-SecretVault -Name $Vault -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
    }
}

Saving, reading and deleting credentials from the vault

To save credentials to the vault, you should use the Set-Secret cmdlet in the SecretManagement module. The secret in this cmdlet is identified by its name only, but in our case a credential is described by two identifiers – the user name and the server it’s intended for. Therefore, in the New-VISecret cmdlet we’re concatenating “VISecret”, the server and user name by using the pipe symbol as a delimiter, and then we’re using the resulting string as an identifier of the secret. If you want to save credentials for more than one product you could extend the function to replace “VISecret” with another product specific string to build the identifier, for example “VMCSecret” for VMC. You can pass the password as a plain text string or as a secure string.

Similarly, when we read a credential from the vault by using Get-VISecret, it concatenates “VISecret”, the server and username to form the identifier. Then it uses the Get-Secret to retrieve the password for the corresponding server and username.

You can also delete a credential from the store by using Remove-VISecret, which again builds the identifier, and calls Remove-Secret to delete the secret from the vault. If you’re using SecretStore as a vault, you can remove all the credentials it stores by calling Reset-SecretStore

function New-VISecret {
    [CmdletBinding()]
    [Alias("Set-VISecret")]
    param (
        [Parameter(Mandatory=$true)]
        [string]$Server,
        [Parameter(Mandatory=$true)]
        [string]$User,
        [string]$Password,
        [securestring]$SecureStringPassword,
        [string]$Vault
    )
    begin {
        if ([string]::IsNullOrWhiteSpace($password) -and (-not $secureStringPassword)) {
            Throw "Either Password or SecureStringPassword parameter needs to be specified"
        }
        if (-not [string]::IsNullOrWhiteSpace($password) -and $secureStringPassword) {
            Throw "Password and SecureStringPassword parameters cannot be both specified at the same time"
        }
    }
    process {
        $params = @{
            "Name" = "VISecret|"+$server+"|"+$User
        }
         if ($password) {
            $params += @{"Secret" = $password}
        } elseif ($secureStringPassword) {
            $params += @{"SecureStringSecret" = $secureStringPassword}
        } elseif ($Vault) {
            $params += @{"Vault" = $Vault}
        }
        Set-Secret @params
    }
}

function Get-VISecret {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory=$true)]
        [string]$Server,
        [Parameter(Mandatory=$true)]
        [string]$User,
        [switch]$AsPlainText,
        [string]$Vault
    )
    process {
        $params = @{
            "Name" = "VISecret|"+$server+"|"+$User
        }
        if ($AsPlainText.IsPresent) {
            $params += @{"AsPlainText" = $AsPlainText.ToBool()}
        } elseif ($Vault) {
            $params += @{"Vault" = $Vault}
        }
        Get-Secret @params
    }
}

Integrated connection experience

The last cmdlet in the sample module is Connect-VIServerWithSecret. It combines the cmdlets above to give you integrated experience, similar to the one that Connect-VIServer provides with VICredentialStore. You can call Connect-VIServerWithSecret with username and password and use the -SaveCredentials parameter to save the credentials in the vault. Then you can call it by passing just the username: Connect-VIServerWithSecret will automatically retrieve the password from the vault and connect you to the vCenter. When you’re using the VICredentialStore, if you only have a single credential saved for a specified server, you could connect with Connect-VIServer without specifying a username. In Get-Secret, however, the -Username parameter is mandatory as we cannot list all saved credentials and check if you only have a single credential saved for the specified server. To enable this experience, we have defined a global variable $global:defaultUser that lets you set a default user name for the Connect-VIServerWithSecret.

Conclusion

By using Microsoft’s SecretManagement and SecretStore modules, you can achieve similar user experience as when you’re using the VICredentialStore. SecretManagement also gives you a rich set of integration options with other third-party vaults, both locally and in the cloud. You can use the sample VISecret module to configure and use vaults in a similar way as with the VICredentialStore.

We are excited to announce that PowerCLI 13.0 was officially released today. It is a major release full of new and exciting features. Here is what you can find in the new PowerCLI 13:

• PowerCLI is now fully multi-platform!
• The vCD module has been updated to support vCD 10.4 and some new features have been added to it.
• Support for vSAN ESA has been added to the vSAN module.
• OS customization spec support has been updated to support IPv6 and customization scripts.
• Seed checkpoint and custom attributes support have been added to the HCX module.
• vSphere and Horizon modules have been updated to support the latest API features of vSphere 8 and Horizon 8 2209.

Let’s take a closer look at some of these features.

Fully Multi-platform PowerCLI

We have started the PowerCLI multi-platform journey back in 2018, just months after Microsoft released the first multi-platform version of PowerShell. Since then, we have gradually improved the multi-platform support by porting more and more modules.

Now we’re happy to announce that PowerCLI 13 is the first fully multi-platform version of PowerCLI. We have ported the last two Windows-only modules – ImageBuilder and AutoDeploy – and now they can run on all supported platforms.

To do that we have made some changes. Since Python is mandatory for the ImageBuilder module to run, we have decided not to bring Python with PowerCLI anymore, but to add it as a prerequisite for using the ImageBuilder module. So in PowerCLI 13, if you are using this module, you will need to have Python 3.7 installed on your machine. You will also need to install some additional packages in Python that the module uses (six, psutil, lxml, pyopenssl). We have added instructions in the PowerCLI User’s Guide on how to install these on all supported platforms. We have also introduced a PowerCLI setting that allows you to set the path to the Python 3.7 installation. For this setting you can use

Set-PowerCLIConfiguration -PythonPath "<path to the Python installation>"

VMware Cloud Director module updates

We have made several improvements in the vCD module in PowerCLI 13. First of all we updated the module to work with vCD 10.4 as well as to support the API features of vCD 10.4 (API version 37.0). But that’s not all. We have also extended some cmdlets with new parameters and parameter sets. For example, we have extended the New-CIVM cmdlet with a new parameter set that allows the creation of a blank VM, as well as the New-OrgVdc cmdlet with a new -StorageProfile parameter. We have also extended the Get-NetworkPool cmdlet to return the NSX-T-backed network pools.

Following some removals on the API side, we have removed the Get/New/Set/Remove-OrgNetwork cmdlets, which were replaced by the Get/New/Set/Remove-OrgVdcNetwork a long time ago.

VMware vSAN Express Storage Architecture support

In PowerCLI 13 we’re also adding support for the new vSAN ESA. You can read more about this new vSAN architecture here. We have introduced several new cmdlets (Get-VsanEsaEligibleDisk and Add/Get/Remove-VsanStoragePoolDisk) and extended some existing ones (New/Set-Cluster and Get-VsanClusterConfiguration) to enable support for vSAN ESA.

NSX module updates

To encourage the usage of the new NSX SDK module, we have added a dedicated chapter for it in the PowerCLI user’s guide. In PowerCLI 13 we are also deprecating the old way of accessing the NSX APIs through the Get-NsxtPolicyService, Get-NsxtGlobalManagerService and Get-VmcSddcNetworkService cmdlets.

HCX improvements

In PowerCLI 13 we’re also adding some new HCX features. The HCX module now allows enabling seed checkpoint and migration of custom attributes.

Certificate issue while upgrading

As a quick reminder – you may encounter a certificate error while updating the existing PowerCLI module via Update-Module, as discussed here. This is because we replaced the certificate that we used to sign the modules with a new one from a new publisher. To resolve this issue, delete the existing module and re-install the module with the Install-Module cmdlet.

Summary

PowerCLI 13 is the first fully multi-platform PowerCLI version, which also comes with updated vCD support, cmdlets for vSAN ESA and much more. For a full list of all improvements and fixes, check the PowerCLI 13.0 release notes. For more information on specific cmdlets, see the PowerCLI Cmdlet Reference.

Let us know in the comments what you think of this release!

The countdown to VMware Explore in San Francisco is on and for the first time in three years we’re gathering together in person to show you the latest VMware technology innovations. And as usual there is a lot of great PowerCLI sessions and labs that you shouldn’t miss. The schedule builder is now live, so make sure that you add these great sessions to you schedule and stay up-to-date with the latest innovation in PowerCLI.

VMware {code} Sessions

Session: What’s New in VMware PowerCLI? [CODE2691US]
Date: Thursday, Sep 1, 1:00 PM – 1:45 PM PDT
Speaker: Kamen Nikolov
Join us for this session to learn about the latest PowerCLI features, such as VMware vCenter Server Appliance services and VMware vSphere certificate management, the new approach for invoking vSphere REST APIs, PowerShell runspace support, extended VMware Cloud on AWS management, and much more. We have prepared interesting demos of the new features, useful scripting tips and tricks, as well as answers to all your questions related to PowerCLI.

Session: Extending the UI with Script Actions – Meet PowerActions [CODE2690US]
Date: Thursday, Sep 1, 12:00 PM – 12:45 PM PDT
Speaker: Kamen Nikolov
Many organizations have a ton of useful VMware PowerCLI scripts developed in-house for VMware vSphere automation. The problem is that these useful and time-saving scripts are only available to those admins that possess enough PowerShell and PowerCLI knowledge to know how to use commands, parameters, variables and so on. What if these scripts were available as easy-to-run actions directly from the vSphere UI? Meet PowerActions, the vSphere UI plug-in that allows extending the UI with custom PowerCLI scripts. PowerActions provides a script library and a user-friendly interface that allows you to build custom scripts through a wizard. PowerActions can be used by anyone in the organization, even if they have never touched PowerShell before. Join our session to learn more about PowerActions and see it in action.

Session: Explore the New PowerCLI for NSX [CODE1881US]
Date: Wednesday, Aug 31, 11:00 AM – 11:45 AM PDT
Speaker: Madhukar Krishnarao
VMware PowerCLI v12.6 introduces new high-level cmdlets to automation with VMware NSX. Learn about these new cmdlets and how to navigate the modules and build code whether NSX is on-premises or on VMware Cloud.

Session: PowerCLI and REST APIs – A New Beginning [CODE2689US]
Date: Thursday, Sep 1, 11:00 AM – 11:45 AM PDT
Speaker: Kamen Nikolov
In the latest PowerCLI versions, we developed a new, more intuitive approach to calling VMware REST APIs. We also built integration with the VMware REST API documentation database, so you can fetch PowerCLI samples directly from the API documentation portal. Join our session and see a demo of how you can easily automate workflows by using VMware vSphere and VMware NSX REST APIs with PowerShell.

Session: Try This, Catch That, Finally – An Explanation on PowerCLI Error Handling [CODE1865US]
Date: Wednesday, Aug 31, 3:00 PM – 3:45 PM PDT
Speaker: Justin Sider
Automation is impossible if your VMware PowerCLI scripts cannot run through to completion. Handling errors properly can greatly improve your code writing skills. Whether the script is a few lines or a few hundred lines, there are great efficiencies to be gained from using try/catch/finally blocks. During this session, Justin will cover the main differences between terminating and non-terminating errors. Examples of each type of error will be shown so you can see the code in action. This session will also cover the ErrorAction parameter. This presentation will have plenty of live code examples interacting with APIs and custom functions to ensure you can see the real-world application of these PowerShell tools.

Hands on Labs

Lab: VMware vSphere Automation – PowerCLI [SPL-HOL-2211-04-SDC]
Date: Anytime the HOL area is open and available
Get hands-on with VMware PowerCLI. Gain familiarity with the tool, and then dive deeper into the functionality available with real-world examples. Both new and experienced users are sure to learn something new about automating their environments.

Lab: Automate your VMware Cloud on AWS [SPL-HOL-2287-04-ISM]
Date: Anytime the HOL area is open and available
Learn about a number of tools that will help you automate your VMware Cloud on AWS environment. See how with PowerCLI and DatacenterCLI can query the status of your SDDC, perform log analysis, security event audits and expand capacity with few commands. Be amazed by the simplicity, value and benefits of using infrastructure as code with Terraform to manage, change or decommission your infrastructure. Take a look at a recent Fling that was published to automatically save the network configuration of your SDDC and restore it to another VMC SDDC.

Also don’t miss the VMware Odyssey by Hands-on Labs, which also includes some PowerCLI tasks

Lab: VMware Odyssey by Hands-on Labs [ODY-HOL-2200-81-ODY]
Date: Anytime the HOL area is open and available
VMware Odyssey by Hands-on Labs is an exciting way to challenge yourself and compete against your peers for the chance to earn prizes and bragging rights. Our Tournament is back in 2022 and more exciting than ever! Each of the first three days of VMware Explore you can complete tasks in a live lab environment, while racing against the clock. Be sure to visit each day as the cumulative leaderboard will show the results in ranked order. The top scores will qualify for the live tournament on the last day, and the winners will be awarded prizes. Be sure to take an Odyssey challenge each day and we’ll see you on the leaderboard!

VMware Explore is the new premier event to learn about the latest PowerCLI news. So if you haven’t registered yet make sure that you do it today and add all those great sessions to your schedule.

The PowerCLI team has some exciting news this week! PowerCLI version 12.7 is out and it’s packed with lots of new and exciting features. We have made a long requested module available on PowerShell Core, extended many cmdlets and added some new ones, and also improved the performance of others.

PowerCLI 12.7 comes with the following updates:

• The VUM module has been ported to PowerShell 7 and now supports Linux and macOS.
• Remote authentication support has been added to Connect-NsxServer cmdlet.
• The usability of Get-NsxOperation cmdlet has been improved.
• The NSX module has been updated with the latest API features.
• The Horizon module has also been updated with the latest API features of Horizon 8.4.
• Support for vSAN health check threshold, historical health check and remote datastores has been added to the vSAN cluster configuration.
• Performance improvements in Connect-SrmServer and Get-HCXVM cmdlets.

Let’s take a closer look at some of these updates.

Multi-platform VUM module

One of the last non-multiplatform PowerCLI modules is now available for Linux and macOS after a lot of customer requests that we received in the last months and years. We started our multiplatform journey shortly after the first PowerShell core version was launched. Since then we’ve ported almost all of the PowerCLI modules with now only two modules left. We’re very happy to see that our hard work in this direction already pays off – PowerCLI is now the multi-platform VMware CLI with more than half of our users today using PowerShell 7 and more than 40% using PowerCLI on Linux and macOS.

NSX module improvements

We have introduced the new NSX SDK module in PowerCLI 12.6. If you haven’t already you can check this great blog post from Madhukar Krishnarao on how to use it to perform the most common NSX operations. In this release we’re updating it with the latest NSX API features, adding remote authentication to the Connect-NsxServer cmdlet with the -UseRemoteAuthentication parameter, and improving the usability of Get-NsxOperation cmdlet.

Let’s dig a bit deeper in the Get-NsxOperation improvements. We have changed the way the -Path parameter works in Get-NsxOperation. In 12.6 it required the path to be in the format that is used in the NSX API specification, which was different from the one that was used in the NSX API documentation. This is now changed and you can just copy/paste the operation URL from the API documentation to get the corresponding PowerCLI cmdlet with Get-NSXOperation as in the example below:

Another change in the -Path parameter behavior is that it no longer returns all the operations that contain the specified path, but only the exact matches. Of course, you can still use wildcards to find multiple operations by part of the path.

New vSAN cluster configuration options

We have added several new vSAN cluster configuration options. You can now set vSAN health check thresholds using the -CapacityThreshold parameter of Set-VsanClusterConfiguration and New-VsanHealthCheckThreshold. You can also enable or disable vSAN historical health check as well as mount or unmount datastore from another cluster as remote datastore using Set-VsanClusterConfiguration. Here are some samples:

$newThreshold = New-VsanHealthCheckThreshold -Enabled $true -YellowValue 95 -RedValue 99 -Target VsanDatastore
Set-VsanClusterConfiguration -Configuration $cluster -CapacityThreshold $newThreshold -HistoricalHealthEnabled $false

$remoteDatastore = Get-Datastore 'MyDatastore'
Set-VsanClusterConfiguration -Configuration $cluster -MountRemoteDatastore $remoteDatastore

Certificate issue while upgrading

You may encounter a certificate error while updating the existing PowerCLI module via Update-Module, as discussed here. This is due to the fact that we replaced the certificate we used to sign the modules with a new one from a new publisher. To resolve this issue delete the existing module and re-install the module with the Install-Module cmdlet.

Summary

PowerCLI 12.7 comes with improved multiplatform support, NSX and vSAN improvements, and SRM and HCX performance optimizations. For a full list of all improvements and fixes check the PowerCLI 12.7 release notes. For more information on specific cmdlets, see the PowerCLI Cmdlet Reference.

Let us know in the comments what you’re looking forward to most!