If you would like to read the other parts in this article series please go to:
- Configuring iSCSI Storage (Part 1)
- Configuring iSCSI Storage (Part 2)
- Configuring iSCSI Storage (Part 3)
Reviewing the scenario
Before we look at how to provision iSCSI volumes on Windows Server 2012, let’s review our walkthrough up to this point.
Figure 1 shows two servers running Windows Server 2012 that we’re using for our walkthrough. SRV-A is our application server that consumes iSCSI storage. The iSCSI initiator has been enabled on this server, and the initiator IQN is iqn.1991-05.com.microsoft:SRV-A.adatum.com.
SRV-B is our storage server that provides block-based iSCSI storage to the application server. SRV-B has direct-attached storage (DAS) in the form of four SATA drives attached to a hardware RAID adapter that uses a SAS bus connection. The RAID adapter has been configured to expose the drives as individual physical disks, that is, no striping, mirroring, or parity has been configured. One of these drives hosts the operating system, while the other three drives are our data drives.
So far we have performed the following configuration tasks on SRV-B:
- The iSCSI Target Server role service has been installed on the server.
- The three data drives have been brought online and formatted as NTFS volumes named X, Y and Z drive.
- Two iSCSI virtual disks have been created on X: drive. These virtual disks are backed by the VHD files vdisk1.vhd and vdisk2.vhd in the iSCSIVirtualDisks folder on this drive.
- Two iSCSI targets have been created on the target server. Their target IQNs are iqn.1991-05.com.microsoft:SRV-B-target1-target and iqn.1991-05.com.microsoft:SRV-B-target2-target and the targets are assigned to virtual disks vdisk1.vhd and vdisk2.vhd respectively.
Figure 1: Where we are at in our walkthrough.
We are now going to perform the following tasks:
- Configure the iSCSI initiator on SRV-A by discovering available targets in the environment for the initiator to connect to and establish a connection between the initiator and one of the available targets.
- Provision a new iSCSI volume for SRV-A and use it just like you would use a local volume on the server.
We will perform all of the above tasks on our application server SRV-A.
Configuring the iSCSI initiator
We’ll begin by opening the iSCSI Initiator Properties dialog by selecting iSCSI Initiator from the Tools menu of Server Manager:
Figure 2: Step 1 of configuring the iSCSI initiator.
The screenshot above shows the Targets tab and at this point no iSCSI targets are configured for the initiator. To discover targets in our environment that the initiator can connect to, switch to the Discover tab:
Figure 3: Step 2 of configuring the iSCSI initiator.
To find iSCSI targets we can connect to from our application server, we first need to find iSCSI target servers which are here called target portals. There are two ways we can do this. First, if we know which servers are portals in our environment, we can click Discover Portal and manually configure the IP address or DNS name of the portal as shown here:
Figure 4: Step 3 of configuring the iSCSI initiator.
Alternatively, if we have an iSNS server in our environment, we can click Add Server in the previous screenshot to specify the IP address or DNS name of the iSNS server. Internet Storage Name Service (iSNS) servers act like DNS servers for an iSCSI infrastructures. Initiators can query them to automatically discover all iSCSI targets present in your infrastructure, making manual configuration of portals unnecessary for your initiators. In a future article we may examine how to implement iSNS in a Windows Server 2012-based iSCSI environment, but for this walkthrough we’ll simply manually specify SRV-B as the target portal for the initiator on SRV-A. Once we’ve done this, the Discovery tab now looks like this:
Figure 5: Step 4 of configuring the iSCSI initiator.
Switching to the Targets tab shows that two targets have been found on the target server. Both of these targets have Inactive as their status because a connection with them has not yet been established by the initiator:
Figure 6: Step 5 of configuring the iSCSI initiator.
Let’s now connect to the target named “target1”. To do this, we select the first target in the list and click Connect to open the Connect To Target dialog:
Figure 7: Step 6 of configuring the iSCSI initiator.
Note that by default after we connect to the target it will be added to the list of targets on the Favorite Targets tab of the iSCSI Initiator Properties dialog. If a target is listed on the Favorite Targets tab, the initiator will attempt to automatically restore connection to that target whenever the initiator computer is restarted.
Once a connection has been established between the initiator on SRV-A and target1 on SRV-B, the status of target1 on the Targets tab changes from Inactive to Connected:
Figure 8: Step 7 of configuring the iSCSI initiator.
There are also other configuration tasks you can perform on the iSCSI initiator if these are needed. For example, you can use the RADIUS tab to configure Remote Authentication Dial-In User Service (RADIUS) authentication by specifying a RADIUS server in your environment. Unlike CHAP authentication which is peer-based, RADIUS authentication happens between a RADIUS server and a RADIUS client. You can also use the Configuration tab to do things like change the initiator name, configure a CHAP secret, configure IPsec tunnel mode addresses, and generate a report of all connected targets and devices.
You can also use Windows PowerShell to configure an initiator and establish a connection to a target on a target server. For example, let’s use Windows PowerShell to connect the initiator on SRV-A to target2 on SRV-B. First, we’ll use the Get-IscsiTarget cmdlet to view a list of available targets on SRV-B like this:
PS C:\> Get-IscsiTarget | fl
IsConnected : True
NodeAddress : iqn.1991-05.com.microsoft:srv-b-target1-target
PSComputerName :
IsConnected : False
NodeAddress : iqn.1991-05.com.microsoft:srv-b-target2-target
PSComputerName :
Note that if the initiator computer has been restarted, the Get-IscsiTarget cmdlet may not return any results unless you refresh the list of targets discovered by the initiator. You can do this either by clicking the Refresh button on the Targets tab of the iSCSI Initiator Properties dialog or by running the Update-IscsiTarget cmdlet on the initiator computer.
The output of the Get-IscsiTarget command shows that the initiator is not yet connected to target2, so let’s now use the Connect-IscsiTarget cmdlet to establish this connection:
PS C:\> Connect-IscsiTarget -NodeAddress "iqn.1991-05.com.microsoft:SRV-B-target2-target"
AuthenticationType : NONE
InitiatorInstanceName : ROOT\ISCSIPRT\0000_0
InitiatorNodeAddress : iqn.1991-05.com.microsoft:srv-a.adatum.com
InitiatorPortalAddress : 0.0.0.0
InitiatorSideIdentifier : 400001370000
IsConnected : True
IsDataDigest : False
IsDiscovered : False
IsHeaderDigest : False
IsPersistent : False
NumberOfConnections : 1
SessionIdentifier : fffffa8013fd8430-4000013700000003
TargetNodeAddress : iqn.1991-05.com.microsoft:srv-b-target2-target
TargetSideIdentifier : 0200
PSComputerName :
Note that the value of the IsConnected property in the above command output is True, which means a connection was successfully established between the initiator and target2. We can view all established connections and their properties by using the Get-IscsiConnection cmdlet like this:
PS C:\> Get-IscsiConnection
ConnectionIdentifier : fffffa8013fd8430-0
InitiatorAddress : 0.0.0.0
InitiatorPortNumber : 192
TargetAddress : 172.16.11.220
TargetPortNumber : 3260
PSComputerName :
ConnectionIdentifier : fffffa8013fd8430-2
InitiatorAddress : 0.0.0.0
InitiatorPortNumber : 3325
TargetAddress : 172.16.11.220
TargetPortNumber : 3260
PSComputerName :
One thing to note at this point is that the output of the previous Get-IscsiTarget command shows that the IsPersistent property of target2 is False. What this means is that this connection won’t persist across a restart of the initiator computer. It also means that target2 is not included in the list on the Favorite Targets tab on the iSCSI Initiator Properties dialog. To make the connection to target2 persist across reboots (and to add it to the list of favorite targets for the initiator) we can use the Register-IscsiSession cmdlet together with the value of the SessionIdentifier property from the output of the Connect-IscsiTarget command above:
PS C:\> Register-IscsiSession -SessionIdentifier "fffffa8013fd8430-4000013700000003"
If you now click Refresh on the Favorite Targets tab of the iSCSI Initiator Properties dialog, the connection to target2 should now be displayed.
Provisioning new iSCSI volumes
We’re now ready to create a new iSCSI volume on our application server. To do this, we’ll start by opening Server Manager on SRV-A (you can also do this from SRV-B if SRV-A has been added to the server pool on SRV-B) and select the Disk page on the File And Storage Services canvas. Note that SRV-A, which in my test lab actually has only one direct-attached disk (the SAS disk shown below) now appears to have three direct-attached disks. The second and third disks however are not directly attached to SRV-A but are actually virtual disks on our iSCSI target server SRV-B. Because the iSCSI initiator on SRV is connected to the two iSCSI targets we created on SRV-B, and because these targets are assigned to two different iSCSI virtual disks on SRV-B, the result is that SRV-A interprets these two virtual disks as if they were directly attached instead of on another server on the network. You can see this in the screenshot by the fact that the Bus Type property of disks 1 and 2 is iSCSI:
Figure 9: Step 1 of provisioning an iSCSI volume.
Both of these iSCSI virtual disks are currently marked as Offline, so let’s right-click on disk 1 and select Bring Online from the context menu. Once disk 1 is online, right-click on it a second time and select New Volume:
Figure 10: Step 2 of provisioning an iSCSI volume.
In the New Volume Wizard, select the local server (SRV-A) as the server to which we want to provision the new iSCSI volume:
Figure 11: Step 3 of provisioning an iSCSI volume.
Next we’ll specify the size of the iSCSI volume we’re creating on SRV-A:
Figure 12: Step 4 of provisioning an iSCSI volume.
We’ll assign E: as the drive letter for the new iSCSI volume on SRV-A:
Figure 13: Step 5 of provisioning an iSCSI volume.
We’ll format the new volume using NTFs and give it a label of ISCSI_VOL_1 like this:
Figure 14: Step 6 of provisioning an iSCSI volume.
Once the wizard is finished, the new iSCSI volume is displayed on the Disks tile as being present on SRV-A:
Figure 15: The new iSCSI volume has been created.
Selecting the Volumes tile displays additional information about the new volume:
Figure 16: Another view of the iSCSI volume.
If we now open Windows Explorer on SRV-A, it appears as if SRV-A has two local hard drives C: and E: like this:
Figure 17: The iSCSI volume behaves like a local disk.
The new iSCSI volume on SRV-A behaves just like directly-attached disk even though it is actually located elsewhere on the network. If we copy a file to it, the bits for the file will be transmitted over the network using the iSCSI protocol. And if we read a file from, the bits for the file will again be transmitted over the network using the iSCSI protocol. But from the perspective of applications running on SRV-A, volume E: is just another local volume on the server.
Conclusion
For more information about the iSCSI Target Server role services on Windows Server 2012, see this link.
For syntax and examples of Windows PowerShell cmdlets for managing the iSCSI Initiator and iSCSI Target Server on Windows Server 2012, see this link.
If you would like to read the other parts in this article series please go to:
