PowerCLI Cookbook

At the PowerCLI prompt, you will execute the Connect-VIServer cmdlet as follows:

Connect-viserver <hostname or IP>

When executed, the code will attempt to perform a single sign-on into the ESXi host, but unless your username is root and you set the same password locally and on ESX, single sign-in will fail. You will be prompted with a normal Windows login window, which is displayed as follows, and you should log in with the root username and the password you specified during your ESXi installation:

Once you successfully log in to the ESXi host, a confirmation message will be displayed with the name or IP address of the ESXi host you connected to, the port, and the user you've connected to, as shown in the following example:

Name                           Port  User
----                           ----  ----
192.168.0.241                  443   root

At this point, the PowerCLI session is connected to a host and ready to execute work.

PowerCLI is straightforward. To retrieve an ESXi host object, just run the following command line:

Get-VMHost

After running the Get-VMHost cmdlet, an object that contains one or more ESXi hosts is returned. You are connecting to a single ESXi host in this example and running Get-VMHost that returns the host object with a single host. If you were connecting against a vCenter instance, Get-VMHost (with no other arguments) would return an object that contains all of the hosts managed by vCenter. When running against vCenter, you can specify a filter with the Get-VMHost cmdlet in order to find one or more hosts that match the specified pattern:

Get-VMHost esxhost*
Get-VMHost VMHOST1

Instead of calling the Get-VMHost cmdlet each time, you need to get the ESXi host. You can store the host object in a variable. PowerShell variables are specified using $ followed by a name. The following is an example of our ESXi host:

$esxihost = Get-VMHost

Because the cmdlets require a VMHost object, you'll again be using Get-VMHost to either populate a variable or to pipe an object to the next object. The first step is to obtain a VMHost object for our target ESXi host. This can be done using the following command line:

$esxihost = Get-VMHost 192.168.0.241

Once you have your VMHost object, you can look at setting up the authentication. The Set-VMHostAuthentication cmdlet needs to be executed. The cmdlet requires several parameters to join an ESXi host to the domain. The syntax needed is displayed as follows:

$esxihost | Get-VMHostAuthentication | Set-VMHostAuthentication -JoinDomain -Domain domain.local -user username -password *****

Executing the cmdlet will prompt you to confirm that you want to join this host to the domain specified. If your answer is Y, the cmdlet will continue and execute the operation as follows:

Perform operation?
Joining VMHost '192.168.0.241' to Windows Domain 'domain.local'.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):Y

Domain          DomainMembershipStatus    TrustedDomains
------          ----------------------    --------------
DOMAIN.LOCAL    Ok

The first step is to get the list of available services from a VMware host. To do this, you use the Get-VMHostService cmdlet and pass the VMHost object into the cmdlet as follows:

$esxihost | Get-VMHostService

The output of the preceding cmdlet will display a list of the available services on the ESXi host along with its policy (whether it is set on or off by default) if it's running. The label is a friendly identifier to find the service you want to configure, but the key is the piece of data you will use to return the single service you want.

In this case, we're looking to configure the service with the TSM-SSH key. To scope the results down to that one service in the object, you will use a PowerShell where clause as follows:

$esxihost | Get-VMHostService | where { $_.key -eq "TSM-SSH" }

Now that you have it scoped down to a single service, you pass this object into the Set-VMHostService cmdlet with the desired policy of On as follows:

$esxihost | Get-VMHostService | where { $_.key -eq "TSM-SSH" } | Set-VMHostService -Policy "On"

At this point, you have configured the host to autostart the service on boot, but the service is still not running in the current boot. To do this, you will instead use the Start-VMHostService cmdlet. Again, you have to pass in the VMHostService object for SSH (or any other service that you choose).

$esxihost | Get-VMHostService | where { $_.key -eq "TSM-SSH" } | Start-VMHostService 

With the service running, vSphere displays the warning that you have enabled SSH. This will leave your host showing in a warning state as long as the service is running; however, VMware does allow you to suppress this warning, but this is set through an advanced setting. To set this, you need to execute the following cmdlet:

$esxihost | Get-AdvancedSetting –Name UserVars.SuppressShellWarning | Set-AdvancedSetting –value 1

When executed, the preceding command line will prompt you to confirm the settings. This confirmation can be suppressed using the –Confirm:$false common parameter, which is useful in scripts:

$esxihost | Get-AdvancedSetting –Name UserVars.SuppressShellWarning | Set-AdvancedSetting –value 1 –Confirm:$false

To begin with, let's get an idea of the network layout that is in place, by default. From a default install, there is a single virtual switch named vSwitch0. The first cmdlet shows you the properties of this virtual switch and the second shows you the port groups associated with that vSwitch. To do this, review the output of the two PowerCLI cmdlets:

$esxihost | Get-VirtualSwitch
$esxihost | Get-VirtualPortGroup –VirtualSwitch vSwitch0

The first thing to be completed is to remove the default VM Network port group, since it's not the best practice to have Virtual Machine traffic on the management ports, and this default port group is not a part of the design you outlined for this configuration:

$esxihost | Get-VirtualPortGroup -Name "VM Network" | Remove-VirtualPortGroup –Confirm:$false

The preceding command combines the Get-VirtualPortGroup and Remove-VirtualPortGroup cmdlets to change the confirmation. When executed, you will receive either a confirmation or an error. If the port group is connected to or in use by a VM, you will receive an error message. Once you remove the VM Network port group, the next step is to add an additional vmkernel port that will be used for vMotion.

In our design, you will set Management and vMotion to be collocated on the same switch. To do this, use the New-VMHostNetworkAdapter cmdlet and pass in the name of the port group, the virtual switch, and the IP information. You will also pass in a parameter to specify that this vmkernel port should be used for VMotion as follows:

$esxihost | New-VMHostNetworkAdapter -PortGroup "VMotion Network" -VirtualSwitch vSwitch0 -IP 192.168.50.241 -SubnetMask 255.255.255.0 -VMotionEnabled $true

In our design, although vMotion and Management traffic exist on the same vSwitch, the traffic will be separated using active and standby links on each port group. This is done by changing the NIC Teaming Policy with the Set-NicTeamingPolicy cmdlet. You can see in the following two commands that the active and standby NIC assignments are opposite between the two port groups:

$esxihost | Get-VirtualPortGroup -Name "Management Network" | Get-NicTeamingPolicy | Set-NicTeamingPolicy –MakeNicActive vmnic0 –MakeNicStandby vmnic1

$esxihost | Get-VirtualPortGroup -Name "VMotion Network" | Get-NicTeamingPolicy | Set-NicTeamingPolicy –MakeNicActive vmnic1 –MakeNicStandby vmnic0

The port group is automatically created and the vmkernel/host port is created for our vMotion network, but it's on the wrong VLAN. Our vMotion traffic is on a different VLAN, so you need to set this on the port group as follows:

$esxihost | Get-VirtualPortGroup -Name "VMotion Network" | Set-VirtualPortGroup –VlanID 50

The next step is to create a new virtual switch with its own uplinks on vmnic2 and vmnic3, as shown in our diagram. To confirm that the physical NICs exist, you can run the following cmdlet:

$esxihost | Get-VMHostNetworkAdapter

The Get-VMHostNetworkAdapter cmdlet displays all of the vmkernel ports along with all of the physical NICs present on the host.

After confirming the NIC, you will run the New-VirtualSwitch cmdlet to provision the new virtual switch. This cmdlet provisions the vSwitch with its uplinks, but it's currently an island with no connectivity for Management or virtual servers:

$esxihost | New-VirtualSwitch -Name vSwitch1 -Nic vmnic2,vmnic3

The next step is to create vmkernel ports for storage traffic and replication traffic. These are created in the same way as the VMotion Network we provisioned earlier:

$esxihost | New-VMHostNetworkAdapter -PortGroup "Storage Network" -VirtualSwitch vSwitch1 -IP 192.168.100.241 -SubnetMask 255.255.255.0 -VsanTrafficEnabled $true

$esxihost | Get-VirtualPortGroup -Name "Storage Network" | Set-VirtualPortGroup –VlanID 100

$esxihost | New-VMHostNetworkAdapter -PortGroup "FT Logging Network" -VirtualSwitch vSwitch1 -IP 192.168.200.241 -SubnetMask 255.255.255.0 -FaultToleranceLoggingEnabled $true

$esxihost | Get-VirtualPortGroup -Name "FT Logging Network" | Set-VirtualPortGroup –VlanID 200

Again, you want to make sure that our Storage Traffic and Fault Tolerance traffic don't end up competing for bandwidth. Therefore, you will assign one port group to be active on one uplink and the other port group to be active on the second uplink. This is done again with the Set-NicTeamingPolicy cmdlet:

$esxihost | Get-VirtualPortGroup -Name "Storage Network" | Get-NicTeamingPolicy | Set-NicTeamingPolicy –MakeNicActive vmnic2 –MakeNicStandby vmnic3

$esxihost | Get-VirtualPortGroup -Name "FT Logging Network" | Get-NicTeamingPolicy | Set-NicTeamingPolicy –MakeNicActive vmnic3 –MakeNicStandby vmnic2

The final step of our network provisioning is to create new port groups for Virtual Machine traffic. You have set all of the virtual machine traffic to its own vSwitch and uplinks in the design outlined. The first step is to create the virtual switch like you did for vSwitch1 as follows:

$esxihost | New-VirtualSwitch -Name vSwitch2 -Nic vmnic4,vmnic5

Once the virtual switch is created, you can create two port groups on the virtual switch. However, in this case, New-VirtualPortGroup doesn't allow any pipeline input, so you will need to specify the server as a parameter instead of passing it through the pipeline:

New-VirtualPortGroup -Name "Infrastructure Network" -VirtualSwitch vSwitch2 -VLanId 1 -Server 192.168.0.241

New-VirtualPortGroup -Name "Application Network" -VirtualSwitch vSwitch2 -VLanId 2 -Server 192.168.0.241

The simplest of all datastores to provision is an NFS datastore. A single PowerCLI cmdlet will provision an NFS datastore. The New-Datastore cmdlet will take all of the input needed to provision the new datastore and make it available for use. Since NFS does not use the VMFS filesystem, there are no filesystem properties that need to be passed. To connect NFS, you just need to provide a name for vSphere to identify the datastore, a path (the export), and the host that is providing the NFS, as follows:

$esxihost | New-Datastore -Nfs -Name DataStoreName -Path /data1/export -NfsHost nfsserver.domain.local

With this, you've got your first datastore presented and ready to host virtual machines. For NFS, this is all that is required.

iSCSI and Fibre Channel storage is a bit more complex to provision from a PowerCLI and vSphere perspective. Provisioning storage on either of these protocols will require additional decisions to be made when creating the datastore. iSCSI also requires additional configuration steps that are not needed with Fibre Channel. We will focus on iSCSI in this example and I will make a note of where the concepts overlap with Fibre Channel.

iSCSI is an IP-based storage protocol, and as such, you will need to do a bit of network configuration to set up iSCSI to work in our environment. The first thing that needs to be done is to enable iSCSI and to create a software iSCSI target, as follows:

$esxihost | Get-VMHostStorage

By default, there isn't a software iSCSI target that is created. To create this, you need to expand on the previous cmdlet and set this value to true, as follows:

$esxihost | Get-VMHostStorage | Set-VMHostStorage -SoftwareIScsiEnabled $true

The next step is to set the iSCSI targets using the New-IscsiHbaTargets cmdlet. This cmdlet requires that you pass in the iSCSI HBA as an object, so first, you retrieve the iSCSI HBA using Get-VMHostHba and store it in a variable and then use it with New-IscsiHbaTargets:

$iSCSIhba = $esxihost | Get-VMHostHba -Type iScsi

New-IScsiHbaTarget -IScsiHba $iSCSIhba -Address $target -ChapType Required -ChapName vSphere -ChapPassword Password1

The final step of the initial iSCSI configuration is to bind the iSCSI HBA to a specific port. Since you created a Storage Network management port, this is the port that you want to use. To make this change and to remove any other ports, you have to use the ESXCLI interface within PowerCLI. There isn't a native PowerCLI cmdlet for this function:

$esxcli = Get-ESXCLI -VMHost $esxihost
$esxcli.iscsi.networkportal.add($iscsihba, $true,"vmk2")

In our case, the vmkernel port assigned to the Storage Network port group is vmk2. Using the ESXCLI interface, you can assign it to the iSCSI HBA. To confirm the change, you can use the list() method, as follows:

$esxcli.iscsi.networkportal.list()

As you will see, there are other vmkernel ports listed. In my case, vmk0; you can remove them with a simple remove() method, as follows:

$esxcli.iscsi.networkportal.remove($iscsihba,$true,"vmk0")

Now that the system has its targets configured, if the iSCSI array has provisioned storage to the host, it should be visible. This is the point where iSCSI and Fibre Channel converge. Since iSCSI uses the host bus adapter model that Fibre Channel invented, they work in the same way after initial configuration. You must run the NFS mount on each server and you must set up iSCSI initial configuration on each host. Scanning and formatting VMFS datastores only needs to be done from a single host for iSCSI and Fibre Channel disks since they are shared resources. This means that when scripting the steps on each host, the next few steps only need to be done on a single host in the cluster and then every host needs to be a rescan:

$esxihost | Get-VMHostStorage -RescanAllHBA -RescanVmfs

Starting with a rescan is a good idea so that your system recognizes all of the storage changes and sees all disks that have been presented. Whether you're using software or hardware iSCSI, Fibre Channel, or converged network adapters, this is the point where your hosts see its SAN disks.

At this point, your ESXi system doesn't have iSCSI or Fibre Channel datastores that it can use. Even though the disk is visible, it is unformatted and not ready to host VMs. To discover your disks and to enumerate the data you need to configure it, you will need to use the Get-ScsiLun cmdlet:

$esxihost | Get-ScsiLun

This returns a list of disks available to the SCSI subsystem under ESXi. The list might contain a lot of objects. You can use various properties returned by the ScsiLun object to identify and leverage the list for provisioning. For instance, you can scope the list using the Vendor property or by the model. For the purpose of this example, we will assume that you have a disk identified by the iSCSIDisk model and use that for scoping. To create a new datastore on the disk, you need the canonical name, which is also a property in the ScsiLun object:

$LUN = $esxihost | Get-ScsiLun | Where {$_.Model -like "iSCSIDisk"} 

In situations where you have many disks presented to a host, identification by model might not be the best. Another method would be to use the RuntimeName property that enumerates the HBA, controller, target, and the LUN number. For instance, if you know the LUN number you want to prepare is LUN 8 that is represented in the RuntimeName as L8, the PowerCLI to scope and return this would be as follows:

$LUN = $esxihost | Get-ScsiLun | Where {$_.RuntimeName -like "*L8"} 

By storing the LUN in a variable, we can verify the returned value to ensure that you have the correct object and number of objects expected before passing it into the New-Datastore cmdlet:

$esxihost | New-Datastore -Name iSCSIDatastore1 -Path $LUN.CanonicalName -VMFS

This provisions the disk as a VMFS filestore and allows it to be used for VM storage. At this point, you can initiate a rescan on all of the ESXi hosts in the cluster and they will all see the same shared storage.

PowerCLI provides the Get-AdvancedConfig cmdlet that lets us peer into the advanced settings of the ESXi host. Even in the GUI, the syslog settings for an ESXi host are set within the Advanced Configuration setting. If you enumerate all of the advanced settings and then scope for items with syslog.global, you will see the settings you want to adjust to set centralize logging:

$esxihost | Get-AdvancedSetting | Where {$_.Name -like "syslog.global*"}

The two settings you want to adjust are: logDirUnique that sets a subdirectory for each host in the cluster, and logDir that sets the centralized location.

The logDirUnique setting is an easy one. First, you will need to scope down to retrieve just that setting and then pipe it into the Set-AdvancedSetting cmdlet:

$esxihost | Get-AdvancedSetting | Where {$_.Name -like "Syslog.global.logDirUnique"} | Set-AdvancedSetting -value $true -Confirm:$false

The second directory takes a bit more configuration. The logDir setting is a string that defines a storage path. So in our case, you need to figure out which datastore we're going to locate the syslog files onto. The VMFS datastore is identified as a bracketed name, which is followed by a path name. In the earlier example, you created a datastore called iSCSIDatastore1 and you will now use it as our syslog global directory:

$esxihost | Get-AdvancedSetting | Where {$_.Name -like "Syslog.global.logDirUnique"} | Set-AdvancedSetting -value "[iSCSIDatastore1] syslog" -Confirm:$false

Alternatively, if you want to direct all log files to a centralized syslog server, you can set this setting, the Syslog.global.logHost value.

To set the syslog host value, you will use the same cmdlet used to set the previous values for syslog, except that you will alter the advanced setting used in the Where statement. The value should be Syslog.global.logHost to locate the correct value to be set:

$esxihost | Get-AdvancedSetting | Where {$_.Name -like "Syslog.global.logHost"} | Set-AdvancedSetting -value " tcp://syslogserver:514 " -Confirm:$false

To connect to vCenter, use the same cmdlet that you used in the Connecting to an ESXi host or a vCenter instance recipe:

$vcenter = connect-viserver vcentersrv.domain.local 

Once connected to vCenter, you can use the Add-VMHost to add the host into inventory:

Add-VMHost -Server $vcenter -Name esxsrv1.domain.local -Location "Primary"

When prompted, enter the administrative account credentials for the ESXi to perform the join operation.

The host is now added to vCenter Server and can be administered by the server.

First things first, let's begin with pseudocode/documentation of what you want to accomplish. In between each of these sections, you will insert the code you have previously developed individually and put them into a full file:

# Script to mass configure ESXi hosts
# Step 1 - Store credentials for ESXi hosts
# Step 2 – Set a list of target ESXi hosts and IP settings
# Step 3 – Write a ForEach loop to iterate through hosts
# Step 4 – Connect to ESXi host
# Step 5 – Obtain a VMHost object to use for configuration
# Step 6 – Join the ESXi system to Active Directory
# Step 7 – Enable services on the ESXi host & set firewall
# Step 8 – Configure the network settings
# Step 9 – Configure NFS & iSCSI settings
# Step 10 - Join hosts to vCenter
# Step 11 - Rescan for storage changes
# Step 12 – Configure persistent syslog storage

Since you want this script to do as much without any manual intervention, you will want to try and eliminate as many prompts as possible. Since you will be connecting to and executing commands on multiple ESXi hosts, you would normally get prompted to login each time you connect to a host. To avoid this, you can store the credentials in a variable and pass them to each connect-viserver cmdlet.

# Step 1 - Store credentials for ESXi hosts
$esxiCreds = Get-Credential

You're going to use an array of hostnames to connect to individual ESXi hosts for configuration. To create the array, you set a variable and store a comma separated list of addresses to connect to. The addresses can either be hostnames or IP addresses. For this example, you will use IP addresses, but they can easily be fully qualified domain names:

# Step 2 - Set a list of target ESXi hosts and IP settings
$esxiTargets = "192.168.0.241","192.168.0.242", "192.168.0.243", "192.168.0.244"

For the network configuration settings, you will need to set up some additional settings. Since each host has three additional vmkernel ports configured, you need to build a different address for each of these to be used in Step 8. To allow this, you will create three additional variables that contain the first three octets of the network for each vmkernel port:

$vMotionNetwork = "192.168.50."
$storageNetwork = "192.168.100."
$ftlogNetwork = "192.168.200."

The next step is to go back and pull in all of the code you had previously written in one form or another. For this, you will reuse the ForEach loop to execute the cmdlets on multiple ESXi hosts:

# Step 3 - Write a ForEach loop to iterate through hosts
ForEach ($hostname in $esxiTargets) {

The curly brace marks the beginning of the ForEach loop. You will close the loop with a right curly brace later in the script. Inside the loop, you're going to include Steps 4 – 9 from the outline.

For the next step, you're going to use our stored credentials to connect to an ESXi host. Immediately after this, you will store our VMHost object for use throughout the rest of the loop:

# Step 4 - Connect to ESXi host
$connectedHost = connect-viserver $hostname -Credential $esxiCreds

# Step 5 – Obtain a VMHost object to use for configuration
$esxihost = Get-VMHost $hostname

For the next several steps, you're just going to pull code you have already developed. Since each step was covered in depth, you will just bring over the code:

# Step 6 – Join the ESXi system to Active Directory
$esxihost | Get-VMHostAuthentication | 
Set-VMHostAuthentication -JoinDomain -Domain domain.local -user username -password ***** -Confirm:$false

# Step 7 – Enable services on the ESXi host & set firewall
$esxihost | Get-VMHostService | where { $_.key -eq "TSM-SSH" } | Set-VMHostService -Policy "On" -Confirm:$false

$esxihost | Get-VMHostService | where { $_.key -eq "TSM-SSH" } | Start-VMHostService -Confirm:$false

# Step 8 – Configure the network settings
$esxihost | Get-VirtualPortGroup -Name "VM Network" | Remove-VirtualPortGroup –Confirm:$false 

For the network settings, you will need three additional IP addresses for the vMotion, Storage, and FT Logging vmkernel ports. You will compute these addresses using the last octet of the service console IP. To do this, you will first retrieve the IP address of the host:

$esxihost_ipaddress = $esxihost | Get-VMHostNetworkAdapter -name vmk0

Next, you will split the string based on the period between octets, then take the last octet of the IP address and store it as a variable. The IP is in a property called IP. To split that IP into an array, you will use the Split() method, which is a built-in PowerShell method that transforms a string into an array by separating characters with the character passed into the method.

For instance, you want to separate the string at the periods of the IP address, so you pass "." into the Split() method. Since the Split() method turns it into an array, you can then reference the element you want to return – the fourth element. However, remember arrays begin count at 0, so you will return element 3 using square brackets.

$lastOctet = $esxihost_ipaddress.IP.Split(".")[3]

The last step to build the address for this host in the ForEach loop is to concatenate the final octet with the network strings to build a full IP address:

$vmotionIP = $vMotionNetwork + $lastOctet
$storageIP = $storageNetwork + $lastOctet
$ftlogIP = $ftlogNetwork + $lastOctet

Now that your unique IP addresses are created on the three additional networks, you can use them with the cmdlets you wrote in the Setting network configuration recipe.

$esxihost | New-VMHostNetworkAdapter -PortGroup "VMotion Network" -VirtualSwitch vSwitch0 -IP $vmotionIP -SubnetMask 255.255.255.0 -VMotionEnabled $true

$esxihost | Get-VirtualPortGroup -Name "VMotion Network" | Set-VirtualPortGroup –VlanID 50

# Create new virtual switch for Storage and FT Logging
$esxihost | New-VirtualSwitch -Name vSwitch1 -Nic vmnic2,vmnic3

# Create vmkernel ports for Storage and FT Logging
$esxihost | New-VMHostNetworkAdapter -PortGroup "Storage Network" -VirtualSwitch vSwitch1 -IP $storageIP -SubnetMask 255.255.255.0 -VsanTrafficEnabled $true

$esxihost | Get-VirtualPortGroup -Name "Storage Network" | Set-VirtualPortGroup –VlanID 100

$esxihost | New-VMHostNetworkAdapter -PortGroup "FT Logging Network" -VirtualSwitch vSwitch1 -IP $ftlogIP -SubnetMask 255.255.255.0 -FaultToleranceLoggingEnabled $true

$esxihost | Get-VirtualPortGroup -Name "FT Logging Network" | Set-VirtualPortGroup –VlanID 200

# Create new Virtual Switch for Virtual Machines
$esxihost | New-VirtualSwitch -Name vSwitch2 -Nic vmnic4,vmnic5

# Create Port Groups for Virtual Machines
New-VirtualPortGroup -Name "Infrastructure Network" -VirtualSwitch vSwitch2 -VLanId 1 -Server $connectedhost

New-VirtualPortGroup -Name "Application Network" -VirtualSwitch vSwitch2 -VLanId 2 -Server $connectedhost

# Step 9 – Configure NFS & iSCSI settings
# Connect NFS datastore
$esxihost | New-Datastore -Nfs -Name DataStoreName -Path /data1/export -NfsHost nfsserver.domain.local

# Configure iSCSI Settings
$esxihost | Get-VMHostStorage | Set-VMHostStorage -SoftwareIScsiEnabled $true$iSCSIhba = $esxihost | Get-VMHostHba -Type iScsi

New-IScsiHbaTarget -IScsiHba $iSCSIhba -Address $target -ChapType Required -ChapName vSphere -ChapPassword Password1

$esxcli = Get-ESXCLI -VMHost $esxihost

$esxcli.iscsi.networkportal.add($iscsihba, $true,"vmk2")

The final part of the ESXi host configuration is closing the ForEach loop and then disconnecting from this host so that you can connect to the next host:

Disconnect-VIServer -Server $connectedHost -Confirm:$false
}

At this point in the initial configuration, you would want to format your datastores on iSCSI or Fibre Channel arrays, but this is not really a repeatable set of steps. I would suggest one of the two things—either configure the datastore manually from PowerCLI or configure it from the GUI and then come back and run the remainder of the script. Since the focus of this example is to make a repeatable configuration script, the datastore formatting doesn't fit since it is a command used just one time .

The next step is to take our hosts and connect them to vCenter. The easiest way to do this is to connect to vCenter and then use Add-VMHost to add them into inventory. While in the same ForEach loop to accomplish this, you can set central syslog and rescan the hosts for all storage changes:

$vcenter = connect-viserver vcentersrv.domain.local
$datacenter = Get-Datacenter "Primary"

Next, you will run through an additional ForEach loop to add the hosts and set their settings in vCenter:

ForEach ($hostname in $esxTarget) {

Now, you are ready to add the host into vCenter from the Joining an ESXi host to vCenter recipe:

# Step 10 - Join hosts to vCenter
Add-VMHost -Server $vcenter -Name $hostname l -Location $datacenter -Credential $esxiCreds

After adding the host to vCenter, you want to store a VMHost object pointing to the host to use with later cmdlets in this loop:

$esxihost = Get-VMHost $hostname

For the next few steps, you will pull the host settings related to rescanning for datastores and setting the syslog settings:

# Step 11 - Rescan for storage changes
$esxihost | Get-VMHostStorage -RescanAllHBA -RescanVmfs

# Step 12 – Configure persistent syslog storage
$esxihost | Get-AdvancedSetting | Where {$_.Name -like "Syslog.global.logDirUnique"} | Set-AdvancedSetting -value $true -Confirm:$false

$esxhost | Get-AdvancedSetting | Where {$_.Name -like "logDir"} | Set-AdvancedSetting -value "[iSCSIDatastore1] syslog" -Confirm:$false

Finally, you will close the loop with a right curly brace.

}