Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsTo fix iSCSI disconnects or slow storage, first determine whether the host has lost a session, lost one or more multipath connections, or still has paths online but is experiencing latency. Then correlate host, network, multipath, and array evidence before changing settings. A single event, ping, or latency reading rarely identifies the cause—and changing path policies or timeouts without checking the array’s supported configuration can make an outage worse.
First determine what failed
“iSCSI disks disconnect,” “failover doesn’t work correctly,” “high storage latency,” and “poor IOPS” describe different symptoms, not one diagnosis. Establish whether the issue is a complete loss of access, a reduction in redundancy, or slow I/O while paths remain available.
| What you observe | What to establish next |
|---|---|
| All paths or sessions to a LUN are lost | Check host session state, adapter and switch links, target availability, and array/controller health. |
| One path is down but I/O continues | Confirm the remaining paths are online and that the intended independent paths use the correct adapters, target portals, and network routes. |
| Paths repeatedly move between online and offline | Look for link flaps, packet errors, MTU or VLAN inconsistency, duplicate target addresses, and target-closed sessions. |
| Paths remain online but I/O is slow | Measure host/device latency, queue pressure, network behavior, and array performance over the same time window. Online paths do not prove that storage is healthy. |
Microsoft’s Windows Server guidance lists network instability, MPIO errors, adapter readiness, VLAN or MTU mismatch, outdated drivers or firmware, and SAN/NAS resource exhaustion among possible causes. Those are leads to test against the incident evidence, not proof that any single one is responsible.
Collect evidence before changing configuration
Record the hypervisor and build, affected host and datastore or LUN, affected virtual machines, incident start time, and any recent network, storage, driver, firmware, or configuration changes. Note whether the problem is continuous or intermittent and whether it affects one host, one LUN, one path, or multiple hosts and LUNs. That scope helps distinguish a local path fault from a shared network or array problem.
#1 Best Overall
- Full-Scale Professional Network-Attached Storage – Business storage solution with hard drives included and optimized to store, share, and back up data for environments of any size.
- Advanced Hardware and Firmware – Product designed for stability and security, capable of handling heavy data loads without dropping performance.
- Purpose-Built for Data Protection – Secure NAS on closed system with 256-bit drive encryption, two-factor authentication, and flexible backup features to keep your data safe.
- Snapshots for Instant Data Backup and Recovery – Snapshots can be created and used to recover data near instantaneously, with little or no system disruptions, and mitigate ransomware.
- Fast Data Transfers – Native 10GbE port for high-speed file transfers with no cable upgrade needed.
- Capture session and path state while the issue is occurring, if possible; a later snapshot may miss a brief path transition.
- Collect adapter and switch-port statistics, link events, and relevant switch logs. Preserve a time window that includes the onset and recovery.
- Record array/controller health and target-side events for the affected LUNs.
- Save the current multipath policy and relevant adapter, driver, firmware, and network settings before modifying them.
For Windows hosts, Microsoft recommends checking host, network, and storage health and documenting changes. On clustered systems, capture cluster logs as well as per-node state. For ESXi, inspect vmkernel.log around the incident and correlate path transitions and SCSI errors with network and array evidence.
Check Windows Server and Hyper-V hosts
Inspect iSCSI sessions, connections, and MPIO paths
Run these commands in an elevated PowerShell session on the affected host:
Get-IscsiConnection
Get-IscsiSession
Get-NetAdapter
Get-NetAdapterStatistics
Get-VMSwitch
mpclaim -s -dUse the iSCSI commands to check whether expected sessions and connections exist; use mpclaim -s -d to inspect MPIO devices and paths. Compare the results with the intended target portals, LUN mapping, and path design. Check disk visibility and health, and confirm that MPIO is configured consistently on every relevant cluster node. A single detected path where multiple independent paths were intended means redundancy has not been established.
Interpret events as clues, not root-cause labels
Windows disconnect investigations may involve Event 157 and iSCSI events 9, 20, 27, 39, or 153. In a failover cluster, CSV pause symptoms can include events 5120, 5142, or 153. These event IDs do not uniquely identify the fault; match their timestamps to session changes, adapter and switch counters, cluster logs, and array events.
Free tools Windows power users keep installed
One-click scans. No signup required.
Check adapter readiness, teaming, and cluster configuration
Confirm that the adapters intended for iSCSI are available when the iSCSI service starts and that the storage network is correctly segregated and routed for the design. Microsoft’s checklist asks: “Are iSCSI, management, and client networks segregated and correctly routed?” For the Windows cluster configuration described in its guidance, do not use the same adapters for iSCSI and production or cluster traffic. Validate this against the exact topology and supported design rather than applying it as a universal rule for every environment.
Windows Server 2022 guidance marks LBFO NIC teaming deprecated for Hyper-V deployments and points to Switch Embedded Teaming (SET). Check the operating-system version and supported network design before changing teaming; do not replace a working configuration based on a generic recommendation.
Investigate Windows latency and CSV symptoms
Use Performance Monitor to collect disk queue and latency data over the affected interval. Check for antivirus or other filter-driver interference, recent updates, current vendor-supported storage and network drivers and firmware, controller distribution, CSV and volume capacity, and physical hardware health. Validate shared-volume access and MPIO on every cluster node when CSV pauses occur. Filesystem allocation-unit recommendations are workload- and volume-dependent; do not apply them indiscriminately to existing volumes.
Check VMware ESXi hosts
Review path transitions and iSCSI errors
Inspect vmkernel.log around the incident for iSCSI receive failures, SCSI errors, and path state transitions. Check device and path state with the supported tooling for the installed ESXi release, then compare host-side evidence with physical switch and storage-array records. A ping that succeeds does not establish that iSCSI sessions, storage queues, or array I/O are healthy.
Investigate software-iSCSI connection flapping
Broadcom identifies target-closed TCP sessions, network errors, inconsistent MTU, duplicate target IP addresses, and SAN or array saturation as possible causes of software-iSCSI connections flapping between offline and online. Verify VMkernel-to-physical-NIC mapping, target addresses, VLANs, routes, and MTU end to end. If those checks do not resolve the network question, capture TCP traffic for analysis by the storage vendor.
Rank #2
- Full-Scale Professional Network-Attached Storage – Business storage solution with hard drives included and optimized to store, share, and back up data for environments of any size.
- Advanced Hardware and Firmware – Product designed for stability and security, capable of handling heavy data loads without dropping performance.
- Purpose-Built for Data Protection – Secure NAS on closed system with 256-bit drive encryption, two-factor authentication, and flexible backup features to keep your data safe.
- Snapshots for Instant Data Backup and Recovery – Snapshots can be created and used to recover data near instantaneously, with little or no system disruptions, and mitigate ransomware.
- Fast Data Transfers – Native 10GbE port for high-speed file transfers with no cable upgrade needed.
Treat failover timing as a scoped configuration issue
A Broadcom article for ESXi 8.x reports a default iSCSI adapter failover duration of 25–35 seconds in the case it describes. During path recovery, pending I/O can fill a device queue and stall guest I/O. This range is specific to that vendor article and its context; it is not a guaranteed failover time for every ESXi release, adapter, or array. Check the applicable host and storage-vendor guidance before altering timeout or queue settings.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify the network and physical paths end to end
For each intended path, trace the host adapter through its switch port and network to the target portal. Confirm that the interfaces, VLANs, routes, MTU, and target addresses agree at every point. Review adapter and switch-port error counters, packet loss, link flaps, cabling, and switch health. Keep iSCSI traffic appropriately isolated from management or client traffic where the design calls for it.
Redundancy means independent usable paths, not merely multiple connections listed by the host. Microsoft recommends different network adapters for iSCSI connections intended to provide redundancy. Confirm that paths do not unintentionally share a failed adapter or network segment, and that each path reaches the expected target and LUN. If only one path is detected, investigate discovery, adapter, network, and mapping configuration before treating the setup as redundant.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Check multipathing, compatibility, and array health
Confirm that every intended path is online and maps to the expected target and LUN. Compare Windows MPIO/DSM or ESXi multipathing settings with the storage vendor’s host configuration guide. Verify that adapter, driver, firmware, hypervisor, and array versions are supported together. On the array, check controller health, target logs, resource exhaustion, and LUN presentation; on the SAN, check zoning and LUN masking.
Do not select a path policy or timeout simply because it improved a different array’s performance. Broadcom describes an ESXi performance case involving Round Robin and a default IOPS limit of 1000 in the environment covered by its article. That is a configuration value in a scoped case, not a universal optimal setting. Only change the Round Robin IOPS limit or path-selection policy when the storage array’s supported configuration and the workload justify it.
Separate slow I/O from loss of paths
Compare measurements across the same incident window. On Windows, use Performance Monitor to examine disk latency and queues. On ESXi, distinguish device or path latency and queue pressure from network round-trip time. Then compare the scope of the impact:
- One path is slow or failing: investigate that adapter, link, switch route, target portal, and path’s controller mapping.
- One host is affected: focus first on its adapters, drivers, firmware, VMkernel or host network configuration, and host-side queues.
- One LUN or controller is affected: inspect its mapping, array controller, and target-side logs.
- Multiple hosts or LUNs are affected: look for shared network, fabric, array, or capacity constraints.
Latency that rises while all paths remain online is not automatically an MPIO policy problem. Check array saturation, queue pressure, network errors, controller distribution, and host filters before changing path selection.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Apply one supported correction, then verify recovery
- Address the fault supported by the evidence: repair a failed cable or link, correct a demonstrated VLAN, MTU, route, target-address, or mapping error, restore MPIO discovery, or resolve an array resource or controller issue.
- If a driver or firmware change is indicated, use the version supported by the server, adapter, hypervisor, and storage vendors.
- Change path-selection or timeout parameters only when the relevant host and storage guidance supports the change for this topology.
- After each change, check that all intended paths return and remain online. Repeat the original health check or workload observation, and confirm whether errors and latency have normalized.
- Keep before-and-after configuration and logs. If the issue remains, provide them with the incident timeline and correlated host, network, and array evidence to the relevant vendors.
Changing one supported variable at a time preserves a clearer cause-and-effect trail and makes rollback or escalation more straightforward.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
