How to Configure Windows Server iSCSI Target Server for Hyper-V Shared Storage

The Cost of Shared Storage

If you deploy a cluster of Windows Server Hyper-V nodes to host enterprise virtual machines, you immediately encounter a fundamental architectural requirement: Shared Storage. If VM 1 is running on Host A, and Host A physically catches fire, Host B must instantly take over the VM. Host B cannot do this unless the VHDX file for VM 1 is located on a shared storage array that both hosts can see simultaneously.

Historically, achieving Shared Storage required purchasing a massive, proprietary Storage Area Network (SAN) appliance (like a Dell EqualLogic or NetApp) connected via physical Fibre Channel cables. This infrastructure costs tens of thousands of dollars.

To shatter this financial barrier, Microsoft built the iSCSI Target Server role directly into Windows Server. iSCSI (Internet Small Computer Systems Interface) is a protocol that allows you to send standard SCSI storage commands over a standard Ethernet TCP/IP network. By enabling the iSCSI Target Server role, you can transform a standard, cheap Windows Server (filled with cheap SATA drives) into a highly capable, software-defined SAN. Your Hyper-V nodes can connect to this server over the network and interact with its virtual drives exactly as if they were physical hard drives plugged directly into their own motherboards.

Step 1: Installing the iSCSI Target Role

First, designate a Windows Server to act as your SAN (e.g., SAN-01). This server should ideally have multiple Network Interface Cards (NICs) and a large RAID array dedicated to storage.

Open an elevated PowerShell prompt on SAN-01 and install the role:

Install-WindowsFeature FS-iSCSITarget-Server -IncludeManagementTools

Unlike a physical SAN, there is no proprietary management IP address to log into. The entire appliance is orchestrated directly through the Windows Server Manager GUI or PowerShell.

Step 2: Creating the iSCSI Virtual Disk (LUN)

An iSCSI Target Server does not simply share folders like an SMB file server. It creates mathematical block-level storage chunks called LUNs (Logical Unit Numbers). In Windows, these are simply massive .vhdx files that the iSCSI service presents to the network as raw blocks.

You can create a 500GB virtual disk using PowerShell:

New-IscsiVirtualDisk -Path "D:\iSCSI_Volumes\HyperV_LUN_01.vhdx" -Size 500GB

This creates a dormant, unattached virtual hard drive on the D: partition of your SAN server.

Step 3: Creating the iSCSI Target (The Access Portal)

The virtual disk exists, but no one on the network can see it. You must create an “iSCSI Target.” A Target is essentially a secure network portal that listens on TCP port 3260.

When you create a Target, you must explicitly define which client servers (Initiators) are allowed to connect to it. You identify the clients using their unique IQN (iSCSI Qualified Name) or their IP addresses. For security, we will lock it to the IP addresses of our two Hyper-V hosts (10.0.5.10 and 10.0.5.11).

New-IscsiServerTarget -TargetName "HyperV-Cluster-Target" -InitiatorId @("IPAddress:10.0.5.10", "IPAddress:10.0.5.11")

Now, map the virtual disk (from Step 2) to this specific Target:

Add-IscsiVirtualDiskTargetMapping -TargetName "HyperV-Cluster-Target" -Path "D:\iSCSI_Volumes\HyperV_LUN_01.vhdx"

The SAN is now fully operational and actively broadcasting the 500GB LUN to those two specific IP addresses.

Step 4: Connecting the Hyper-V Hosts (The Initiator)

Now you must log into your Hyper-V hosts and instruct them to dial out to the SAN.

The client software used to connect to an iSCSI SAN is called the iSCSI Initiator. It is built into every version of Windows, but the service is set to “Manual” by default.

On Hyper-V Host A, start the service and set it to Automatic:

Set-Service -Name msiscsi -StartupType Automatic
Start-Service msiscsi

Now, command the host to connect to the IP address of SAN-01 (e.g., 10.0.5.50):

New-IscsiTargetPortal -TargetPortalAddress 10.0.5.50
Connect-IscsiTarget -NodeAddress (Get-IscsiTarget).NodeAddress -IsPersistent $true

(Note: The -IsPersistent $true flag is critical. It guarantees that if the Hyper-V host reboots, it will automatically reconnect to the SAN before attempting to boot its virtual machines).

Step 5: Initializing the Raw Block Storage

The magic of iSCSI is that it bypasses standard file sharing. If you open Disk Management (diskmgmt.msc) on Hyper-V Host A, you will see a brand new, uninitialized 500GB physical hard drive listed at the bottom of the screen. The Windows kernel genuinely believes it is a physical drive plugged into the motherboard via a SCSI cable; it has no idea the data is traveling over an Ethernet cable.

You must bring the disk online, initialize it as GPT (GUID Partition Table), and format it as NTFS or ReFS (or CSVFS if you are building a Failover Cluster).

Once formatted and assigned a drive letter (e.g., S: for Shared), you can place your Hyper-V VHDX files directly onto this drive. If Host A catches fire, you log into Host B, connect its iSCSI Initiator to the exact same Target, mount the drive, and instantly boot the VMs without losing a single byte of data.

Conclusion

Relying on physical Fibre Channel SANs to achieve hypervisor shared storage introduces massive capital expenditure and hardware lock-in. By deploying the Windows Server iSCSI Target Server role, infrastructure architects can transform standard, commodity x86 servers into highly capable, block-level storage arrays. The ability to provision raw LUNs over standard TCP/IP ethernet, securely map them via IQNs, and dynamically attach them to clustered Hyper-V nodes democratizes enterprise virtualization and mathematically guarantees high availability at a fraction of the cost.