When configuring Windows Server 2012/Hyper-V 2012 R2 initiators to access a CentOS 7-based iSCSI target simultaneously, we encounter a critical filesystem visibility issue. Each initiator appears to maintain its own independent view of the NTFS partition, preventing true shared storage access - a fundamental requirement for VM live migration scenarios.

For successful Hyper-V live migration between hosts using shared iSCSI storage, we need:

• Coordinated SCSI reservation handling
• Proper clustered filesystem awareness
• Consistent multi-path I/O configuration

For CentOS 7 targets using LIO (Linux IO Target), ensure these settings in /etc/target/saveconfig.json:

{
  "storage_objects": [
    {
      "name": "sharedisk",
      "type": "block",
      "attributes": {
        "emulate_tpu": 1,
        "emulate_3pc": 1,
        "enable_shared_access": 1
      }
    }
  ],
  "targets": [
    {
      "tpgs": [
        {
          "attributes": {
            "authentication": 0,
            "generate_node_acls": 1
          },
          "luns": [
            {
              "storage_object": "sharedisk",
              "mapped_lun": 0
            }
          ]
        }
      ]
    }
  ]
}

On Windows Server initiators, execute these PowerShell commands to configure proper shared access:

# Set MPIO policy for iSCSI
Set-MSDSMSupportedHW -VendorId "MSFT2005" -ProductId "iSCSIDisk"

# Configure iSCSI session for shared access
New-IscsiTargetPortal -TargetPortalAddress 10.0.0.100
Connect-IscsiTarget -NodeAddress iqn.2003-01.org.linux-iscsi.centos7.x8664:sn.sharesys -IsMultipathEnabled $true -InitiatorPortalAddress 10.0.0.101 -TargetPortalAddress 10.0.0.100 -IsPersistent $true

# Set disk policy for shared access
Set-Disk -Number X -IsOffline $false -IsReadOnly $false
Set-Disk -Number X -IsClusterShared $true

NTFS fundamentally isn't designed for multi-host concurrent access. Consider these alternatives:

1. CSVFS: Cluster Shared Volumes File System when using Windows Failover Clustering
2. ReFS: More resilient to concurrent access patterns
3. SCSI-3 PR: Implement persistent reservations at the block level

For Hyper-V live migration between ServerA and ServerB sharing an iSCSI target:

# On ServerA (Source):
Move-VM -Name ProductionVM -DestinationHost ServerB -IncludeStorage -DestinationStoragePath \\ClusterStorage\Volume1

# Required cluster configuration:
Add-ClusterSharedVolume -Name "Cluster Disk 1" -Volume "Volume1"

• Partition visibility mismatches: Ensure consistent disk signatures using sg_format --resize on Linux side
• Reservation conflicts: Check /sys/kernel/config/target/core/iblock_0/sharedisk/statistics/scsi_reservation_releases
• Performance degradation: Monitor iscsiadm -m session -P 3 for session statistics

When attempting to configure shared iSCSI storage between Linux targets and Windows initiators for Hyper-V live migration, many administrators encounter the "independent NTFS instances" phenomenon. This occurs when multiple Windows servers mount the same iSCSI target but maintain separate filesystem views, defeating the purpose of shared storage.

The root issue stems from Windows' default iSCSI behavior and SCSI reservation conflicts:

# Typical Linux targetcli configuration (problematic version):
/> /backstores/block create name=shared_vmstore dev=/dev/sdb
/> /iscsi create iqn.2023-04.com.example:storage.vmstore
/> /iscsi/iqn.2023-04.com.example:storage.vmstore/tpg1/luns create /backstores/block/shared_vmstore

For proper shared access, we need both target and initiator modifications:

Linux Target Configuration

# Install required packages (CentOS/RHEL 7):
yum install targetcli fence_scsi

# Configure shared access:
/> /iscsi/iqn.2023-04.com.example:storage.vmstore/tpg1 set attribute generate_node_acls=1
/> /iscsi/iqn.2023-04.com.example:storage.vmstore/tpg1 set attribute cache_dynamic_acls=1
/> /iscsi/iqn.2023-04.com.example:storage.vmstore/tpg1 set attribute demo_mode_write_protect=0
/> /iscsi/iqn.2023-04.com.example:storage.vmstore/tpg1 set attribute default_cmdsn_depth=32

Windows Initiator Setup

PowerShell commands to configure proper shared access:

# Set MPIO policy for iSCSI (run on all Hyper-V nodes):
Set-MSDSMSupportedHW -VendorId "MSFT2005" -ProductId "iSCSIBusType_0x9"

# Configure persistent reservation:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\0*" -Name "EnablePersistentReservations" -Value 1

# Connect to target (repeat on all nodes):
New-IscsiTargetPortal -TargetPortalAddress 192.168.1.100
Connect-IscsiTarget -NodeAddress "iqn.2023-04.com.example:storage.vmstore" -IsPersistent $true -IsMultipathEnabled $true

Test from multiple Hyper-V nodes simultaneously:

# On first node:
Get-Disk | Where-Object {$_.BusType -eq "iSCSI"} | Initialize-Disk -PartitionStyle GPT
New-Partition -DiskNumber X -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "VMStore"

# On second node (should see existing partition):
Get-Partition -DiskNumber X | Get-Volume

For live migration to work:

# Storage settings for VMs:
$vm = Get-VM -Name "TestVM"
Set-VM -Name $vm.Name -AutomaticCriticalErrorAction Pause 
    -AutomaticStartAction StartIfRunning 
    -CheckpointType Production

The key is ensuring all Hyper-V nodes use the same SCSI device identifiers. This can be verified with:

Get-Disk | Where-Object {$_.BusType -eq "iSCSI"} | Select-Object Number,FriendlyName,SerialNumber