Configuring vSAN iSCSI Targets

VSAN_AcceptedTest…Test…Test…This thing on?

Yes it has been awhile since I actually posted something here, so I thought I would kick out something that I have been recently playing with in my home lab and share some thoughts. That being, the ability in vSAN 6.5 to present physical or virtual guests with an iSCSI target served from a vSAN cluster.

Now some might be thinking to themselves “Isn’t the whole idea of HCI to get AWAY from the concept of provisioning storage on a per LUN basis?” And for those thinking that, you are correct! Sadly, that utopia doesn’t quite exist in the real world. Yet. I still have conversations with customers that still have a few hold out workloads or requirements for a bare metal server or some sort of in-guest iSCSI initiators (shivers) and see these a roadblock or limitation to moving to HCI.

Well, in the latest release from VMware’s vSAN product this is not a reality. Guessing there must have been enough of customer/user base demand this functionality for VMware to get rolled into the offering. And before you get a head of yourself, I know what your are thinking and the answer is no. You Cannot present an iSCSI target from a vSAN Datatore to an ESXi host:

Virtual SAN iSCSI target service does not support other vSphere or ESXi clients or initiators, third party hypervisors, or migrations using raw device mapping (RDMs).

A few other things to keep in mind, the following native VMware vSphere features are Not supported when using a vSAN iSCSI target:

  • vSphere Replication
  • vSphere Data Protection APIs (Think how you are going to back them up, this eliminates tools such as Veeam or Cohesity unless using in guest agents)
  • vSphere Snapshots (see above)
  • VMware Site Recovery Manager (SRM)
  • SPBM Policies are fully supported, so R1/R5/R6 and FTT options are available
  • Data reduction services such as deduplication and compression are supported

The Prerequisites

Before we get started, lets map out a few of the prerequisites you are going to want to have in place prior to enabling and configuring the vSAN iSCSI target functionality. They are, in no specific order:

  • A VMKernel interface on each of your ESXi hosts to be used for the iSCSI traffic
  • Preferably a dedicated network/VLAN for the iSCSI traffic
  • A port group created/assigned to assign the VMKernel as well as possible virtual machines that need to access the iSCSI targets

In my lab, as the screen shots below show, I created a new portgroup on my TUK-VDS-Compute vSphere Distributed Switch titled “VDS-Compute-VSAN-iSCSI and created/assigned a new VMKernel interface to each of my ESXi hosts in the 10.1.41.x/24 networks space. This also represents a new non-routable VLAN on my network, VLAN 41.

vSphere Distributed Switch PortGroup


VMKernel Ports Assigned:



Enabling/Configuring iSCSI Targets

The process of enabling and configuring the iSCSI target functionality is pretty straightforward. To save words and pictures, I am going to assume that you are already logged into the vSphere Web Client with credentials that have administrative permission.

Step 1 – Expand your vCenter Server and Datacenter inventory objects. Select your vSAN enabled cluster, Select the Configure tab in the right hand pane, and Expand the Virtual SAN node:


Step 2 – Under the Virtual SAN node, Select the iSCSI Targets object and in the right hand pane Click the Edit button:

Step 3 – Select the check box for Enable Virtual SAN iSCSI target service and from the Storage policy for the home object dropdown Select the SPBM policy you wish to leverage for the home object (Note – I left the default option selected). Click OK:Pic5


Step 4 – With the service enabled, the iSCSI Targets screen will look a bit different and empty. Click the green Plus Sign to create you first iSCSI target:


Step 5 – This will bring up the New iSCSI Target dialog. Provide a Target Alias name and select a SPBM policy from the Target Storage Policy dropdown. As an option, you can also create your first LUN by Checking the Add your first LUN to the iSCSI target check box. I chose to do so and provided the LUN alias, the LUN storage policy (Erasure Coding), and finally the LUN size. Click OK when completed:


Step 6 – With your iSCSI Target and LUN created your screen should look similar to the one below. Next Click the Copy IQN of an iSCSI Target icon to make your next step a bit easier:


Configuring Windows iSCSI Initiator

With the vSAN portion of the work completed, it is time turn towards presenting the LUN to a guest OS. For this I will be using a Windows 2012R2 virtual machine. I have added a second network interface to the virtual machine and placed it into the VDS-Compute-VSAN-iSCSI PortGroup outlined in the Prerequisites section of this post.

Step 1 – Logged into the system with an Administrator enabled account, go to Control Panel, Administrative Tools, and Select the iSCSI Initiator option. This will bring up the iSCSI Initiator Properties dialog. Provide the Target IP address or DNS name (I used IP address) and Click the Quick Connect button:


Step 2 – If everything is setup as expected you see your copied IQN name from the vSAN Targets displayed in the Name box of the iSCSI Initiator Properties dialog. Click OK when ready:


Step 3 – Launch the Disk Management utility and your newly created/presented volume should be displayed. Bring the device online and format as needed:


Final Thoughts

As you can see, creating and presenting an iSCSI target from vSAN is pretty straightforward and easy to do. While I see only a few edge use cases for this functionality, I am glad to see VMware incorporate this option in the latest release of vSAN. Just pay close attention to how you will/want to protect the data as typical tools in a VMware environment will not be available to you.

Thanks for reading!


%d bloggers like this: