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.