By BackToBasics

Configuring iSCSI Storage

Introduction

iSCSI storage is another block-level protocol that present RAW LUNs/Volumes to the ESX host using combination of Ethernet/TCP-IP technologies. iSCSI communications follow the client/server model, with the client often being referred to as the “Initiator” and the iSCSI storage array being the “Target”. iSCSI support was added to vSphere in the 3.5 edition, and has since grown exponentially in popularity.

VMware ESX ships with its own built-in iSCSI Initiator, and using a combination of vSwitch and VMKernel Ports. From a network perspective basic iSCSI communications could be enabled using just a vSwitch backed with two NICs. However, a load-balanced configuration is supported which has more convoluted configuration but pays dividends from a performance perspective. For more details consult this article –  Back to Basics: Creating Standard vSwitches (One of Three) and the section called “Creating an Teamed Standard vSwitch for Load-Balanced iSCSI communications”

As with Fibre-Channel Communications, iSCSI uses an unique value to represent the inbound requests of the initiator referred to as IQN or iSCSI Qualified Name. This a convention which allows for global unique string to be configured for the iSCSI Initiator. The convention is IQN.YYYY-MM.com.domain:hostname. For example

iqn.2013-11.com.corp:esx01nyc

Note: Notice the domain is inverted from the way it is expressed in the FQDN format. No DNS looks are used or required by iSCSI. It’s merely a convention design to ensure uniqueness. The IQN for VMware is configured when you enable the Software iSCSI Initiator. However, the first step in a iSCSI deployment is deciding upon a meaningful IQN convention that guarantees uniqueness.

UPDATE:

This blogpost has been updated with a “Discuss The Options” session with vExpert, Tom Howarth – in the video Tom walks use through the challenges surrounding implementing fibre-channel, iSCSI and NFS storage with vSphere.

The second video which demos managing iSCSI and NFS volumes – together with how to provision new storage using a Synology Diskstation as an example – it also covers the steps to format and grow a VMFS volume. If you’re watching the YouTube version – be sure to set the video to full screen – and use 720p with HD for best quality. If you prefer the native video is also on mikelaverick.com

Alternatively: Native Video

Creating an iSCSI Volume in Dell Equallogics

As with most storage vendors the Dell Equallogics comes with a graphical user interface called “Group Manager” so called because it allows you to manage many arrays in a group mode. Creating a new iSCSI Volume involves giving it a friendly name, a size in GB or TB – and granting access to the LUN for at least 1 iSCSI Initiator. Additionally, you must enable “Allow simultaneous connections from initiators with different IQNs” to allow other VMware ESX host access to it.

Screen Shot 2013-11-27 at 15.52.51.png

Once the Volume has been definied other IQN maybe added to the Access list:

Screen Shot 2013-11-27 at 15.54.28.png

Enabling VMware ESX Software iSCSI Initiator

Once a volume has been created and the access granted, we can next enable the Software iSCSI Initiator on the host itself.

1. >Hosts and Clusters >Select your vCenter >Select the DataCenter >Select the ESX host

2. Click the Manage tab

3. Select the Storage column

4. Select Storage Adapters

5. Click the green + symbol add the Software iSCSI Adapter, and click OK to prompt

Screen Shot 2013-11-27 at 16.25.49.png

Screen Shot 2013-11-27 at 16.27.13.png

This should add the iSCSI Software Adapter, and provide an Edit button that allows you to see the IQN parameter. By default VMware auto-generates an IQN for you, but many administrator prefer to configure their own.

Screen Shot 2013-11-27 at 16.28.55.png

6. Next set the IQN, by clicking the Edit button for the iSCSI Adapter – and type in the IQN or cut and paste it if you prefer

Screen Shot 2013-11-27 at 16.31.00.png

7. Next under the Network Port Binding we can set the two portgroups defined for load-balancing into the list

Screen Shot 2013-11-27 at 16.33.59.png

Screen Shot 2013-11-27 at 16.35.35.png

Finally, we can configure the ESX host with the IP address of the iSCSI Target to connect to – in our case it is the IP address of 172.168.3.69

8. Select the Target tab, and ensure Dynamic Discovery is selected – and click the Add… button.

Screen Shot 2013-11-27 at 16.38.58.png

Rescanning the iSCSI Software Adapter in vCenter

Once a LUN/Volume has been presented, all that is required on the VMware ESX host is a “rescan” of the storage. Indeed, during the configuration of the iSCSI Initiator you may receive prompts to this effect. These can be safely ignored until your configuration is complete.

There are number of ways to do this and different locations. A right-click of Datacenter or Cluster object in vCenter should present the option to rescan every ESX host. It probably best to do this on the properties of a cluster, if you have one – since every host within a cluster will need to see the same storage. It could be regarded as “dangerous” to do full datacenter wide-scan if you environment contains many ESX hosts and Clusters.

Screen Shot 2013-11-27 at 14.12.43.png

Screen Shot 2013-11-27 at 14.24.03.png

Alternatively, refreshes and rescans of storage can be done a per-host basis from the Storage Adapter location. Three different icons control the rescan process.

The first icon merely carries out a refresh of the overall storage system; The second icon rescans all storage adapters; and the third icon rescans just the selected storage adapter.

Screen Shot 2013-11-27 at 16.42.51.png

Once the rescan had completed you should see a new LUN/Volume mounted to the ESX host under the “Devices” Tab associated with a HBA and under “Storage Device” category.

Screen Shot 2013-11-27 at 16.43.45.png Screen Shot 2013-11-27 at 16.45.50.png

Managing CHAP Settings vCenter

WARNING:

Once a iSCSI TCP Session has been established to the storage array these persist. Even if the permission on the ACL on the LUN/Volume are changed it appears these are not checked until next time the LUN/Volumes are mounted. Merely, rescanning the storage is insufficient to validate the settings for CHAP have been correctly set. Many would recommend a full reboot of the VMware ESX host to verify CHAP has been correctly configured for the first time. Once correctly configured so long as all the hosts are configured in the same way then you can rest assured that security is in place as expected. This occurs because once a iSCSI session is established (eg a login occurs), it remains in place until someone logs out (the target or the initiator). Once you create a connection to the volume on the array, if you then change the access controls, nothing will happen until a logout and an attempted login occurs, at which point the access controls will be checked. From ESXi under the iSCSI initiator, it is possible to delete these Static Paths – and the attempt a rescan which triggers a full login and discover of the iSCSI connections. You can look at these Static Paths as a “caching session” that removes the necessity to authentication ever time an iSCSI transaction takes place.

In addition to the iSCSI IQN its possible to enable another level of security to accessing iSCSI volumes using the Challenge-Handshake Authentication Protocol (CHAP). It is possible to have both Target CHAP and Client CHAP where both the Storage Array and the Client (in this case the ESX host) each provides a shared password or “secret” to allow them to mutually authenticate to each other. Generally, CHAP is not widely used in vSphere environments as many people consider a private dedicated network sufficiently secure. However, it is the case that IQN conventions are quite easy to guess and once a system has valid IP address to reach the storage – there is really nothing stopping a rogue administrator potentially mounting storage to any client with a suitable iSCSI stack installed to it.

CHAP authentication settings do allow for “negotiated” authentication by which authentication is attempted, but not made mandatory. This can be useful in range of environments where different levels of CHAP authentication is supported. Typically the Target side CHAP username and password is configured on the array. Once the CHAP username/password has been established then on a LUN/Volume and then CHAP username is specified as requirement along side a valid iSCSI IQN..

Screen Shot 2013-12-11 at 09.11.42.png

Screen Shot 2013-12-11 at 09.13.41.png

On the VMware ESX host there are two places where authentication maybe handled – on the iSCSI Adapter itself or the Target IP configuration. By default the iSCSI Adapter is the default location. This assumes the same CHAP password is used to access all the iSCSI Storage Array in your environment. Such a configuration maybe regarded by some as inheriently insecure – as once storage arrays CHAP password is known for a specific volume then its is none for all the storage arrays.

To Set CHAP on iSCSI HBA

1. Navigate to the ESX host, Select the Manage Tab and Storage Column

2. Select Storage Adapters, and select the iSCSI Software Adapter

3. Select the Properties Tab and Click the Edit button, under Authentication

Screen Shot 2013-12-10 at 14.59.33.png

4. In the Authentication Method pull-down list select the authentication model desired

In this case the dialog box presents four option. Three are unidirectional (from the ESX host to the iSCSI Target) and fourth is a bidirectional (a CHAP password exists on the ESX host and on the iSCSI Target – such as VMw@re1! and ESXho$t). The notes below are taken from the online VMware Documentation.

Screen Shot 2013-12-10 at 15.34.41.png

  • Use unidirectional CHAP if required by target – in this case the ESX host prefers a non-CHAP connection, but can use a CHAP connection if required by the target
  • Use unidirectional CHAP unless prohibited by target – in this case the ESX host prefers CHAP, but can use non-CHAP connections if the target does not support CHAP
  • Use Unidirectional CHAP – in this case ESX requires successful CHAP authentication. The connection fails if CHAP negotiation fails
  • Use bidirectional CHAP – in this case the ESX host send the Target password, and the Storage Array sends the Client password – if both match then the iSCSI volume is mounted.

Use Unidirectional CHAP is the most secure method. It means any LUN/volume on the storage array that does not have both an IQN and CHAP name configured will not presented to the VMware ESX. The other options allow for the ESX to negotiate a lower-level of authentication, and potentially gain access to a LUN/Volume merely by IQN alone. This does require the storage administrator to consistently set a CHAP name for every LUN/volume created for ESX. You may find these different ways of handling CHAP confusing, but they are reflection of the many different ways that CHAP can be configured on various storage arrays.

5. Clear the tick next to Use Initiator Name, and input the CHAP Username configured on the storage array – in this case vmware

6. In the Secret field type the password configured at the Storage Array – in this case VM@re1!

Screen Shot 2013-12-11 at 09.31.32.png

To Set CHAP on Per Target Basis

1. Navigate to the ESX host, Select the Manage Tab and Storage Column

2. Select Storage Adapters, and select the iSCSI Software Adapter

3. Select the Targets Tab and Click the Authentication

Screen Shot 2013-12-10 at 15.06.23.png

4. Remove the tick next to the option to Inherit settings from parent – vmhbaNN

5. Clear the tick next to Use Initiator Name, and input the CHAP Username configured on the storage array – in this case vmware

6. In the Secret field type the password configured at the Storage Array – in this case VM@re1!

Screen Shot 2013-12-11 at 09.36.11.png