VDI Logon Stalls During the Backup Window

The evidence points to front-end port contention, not array back-end or SRP pressure:

• Two of four switch ports in the shared port group are above 90 % busy while the other two are near idle. That is a path imbalance, not a capacity wall.
• Array-wide front-end utilisation of 61 % is an average that hides the hot pair.
• Back-end directors at 44 % and SRP at 71 % with 1.5:1 compression leave no plausible array-side bottleneck.

Confirm with:

1. Performance > Analyze, response-time breakdown into front-end and back-end components for SG_BKP. If front-end request time dominates and back-end time stays near baseline, the queueing is at the port/HBA.
2. Per-port IOPS, MB/s, % busy and queue depth for all four PG_FC1 ports across the same window, not just the peak sample.
3. Per-initiator (HBA) statistics for the media servers to see which initiators map to the two hot ports.
4. Storage-group-level IOPS and MB/s for SG_BKP to see whether the 64 Gb HBA upgrade simply doubled per-path demand on half the ports.

Host-side is unlikely to be the cause: host-side symptoms would show high host queue depth and long array response times across all four ports, not two hot and two cold.

The two storage groups are masked through the same port group, so both masking views use the same four front-end ports. Everything SG_VDI does shares those ports' queues, buffers and director CPU with the backup streams. When the backup pushes hard, it fills the queues of the two ports it happens to be using; VDI I/O that maps to those ports waits behind it, which is why users see second-scale stalls during logon bursts even though the array has spare back-end capacity.

Why only two ports: MPIO path selection. With FC the host picks paths per device using its own policy (fixed preferred paths, least-queue, round-robin with a large interval, or vendor PSP). After the HBA upgrade the media servers opened more concurrent streams, and those streams resolved onto the same subset of target ports. The imbalance is a path-selection outcome, not a device placement problem.

Fix direction: either broaden the port set the backup can use (add ports on the second director to the port group, or give backup its own port group and dedicated ports), or cap the backup's per-initiator throughput so it cannot monopolise the shared queues. Also note that all four ports being on one director is a separate fault-domain weakness that this incident has exposed.

Order by risk/impact:

1. Cap the backup host with Host I/O Limits on its initiator group (IOPS and MB/s). Non-disruptive, reversible within minutes, affects only the media servers. Side effect: the backup window lengthens - check that the projected completion still fits before 02:00 before committing.

2. Add ports on the second director to PG_FC1. Non-disruptive on the array, but a port group is shared, so every host using that port group gains new paths and must be rescanned to use them, and every host's zoning must be updated. Plan this as a change window, not a hot fix; it also fixes the single-director fault domain.

3. Move the backup workload to its own port group and masking view on dedicated ports (new zones, new MV). Cleanest isolation, no host downtime, but more objects to manage.

4. Only after isolation, revisit service levels. Changing SG_BKP's SLO from Gold does not address port queueing and could reduce its priority against VDI, so it is not a fix for this symptom.

Finally, verify path policy on the media servers: round-robin with a short interval, or least-queue, spreads better than fixed preferred paths and prevents recurrence.