I85PREP
⌘ K
Dell PowerMax Operate study materials
Dell PowerMax Operate study resources

Cluster Host Sees Four LUNs but Only Two Paths

Dell PowerMax Operate · Put your knowledge to work in context.

All case studies

Cluster Host Sees Four LUNs but Only Two Paths

A two-node Linux cluster needs four 2 TB volumes. You create storage group SG_APP_PROD with four thin volumes and one masking view MV_APP_PROD, using initiator group IG_APP_PROD (both nodes' four HBAs) and existing port group PG_FE_01 (four front-end ports). After rescan, node A sees four devices and eight paths; node B sees four devices but only two paths, and PowerPath marks two previously known paths dead. Zoning shows node B's two HBAs are each zoned to only one of the four ports in PG_FE_01, while node A's two HBAs are zoned to all four ports. The host team asks whether to create a second masking view for node B to 'fix the LUN count' and wants to add two volumes tomorrow. The change window is 30 minutes; the array is a PowerMax 2500 running PowerMaxOS 10. You must avoid disrupting node A.

1. What is the most likely reason node B has only two paths, and why is a second masking view not the right fix? What would you verify in Unisphere and SYMCLI before changing anything?

Read the worked answer

Node B already sees all four devices, so the array is presenting the LUNs. The problem is path-level: each of node B's two HBAs is zoned to only one front-end port in PG_FE_01, so it can log in through only two ports. The 'dead' paths are likely stale entries from a prior zoning state; a rescan alone will not create new paths if the zone set does not allow them.

Before changing anything, verify the full masking chain:

  • symaccess -sid <sid> show view MV_APP_PROD to confirm the view uses IG_APP_PROD, SG_APP_PROD, and PG_FE_01.
  • symaccess -sid <sid> list logins or Unisphere Hosts > Initiators to confirm which HBA WWNs are actually logged in and to which ports.
  • Unisphere port group membership and switch zone sets to confirm node B's HBAs are zoned to the intended ports.

A second masking view would not add paths. It would duplicate the same volumes under another view and can give node B different LUN addresses, create duplicate device entries, and cause cluster or multipath confusion. Separate masking views are justified for different LUN offsets, different port groups, or different host access requirements, not for correcting zoning.

2. The host team proposes a second masking view for node B with a separate storage group containing the same four volumes. What risks does that introduce, and when would separate masking views be justified?

Read the worked answer

The proposal creates two independent array-side presentations of the same underlying volumes. Risks include:

  • Node B may see the same volume with a different LUN ID from what node A sees, which is risky for clustered volume managers and ASM or filesystem discovery.
  • Two storage groups must be kept in sync whenever capacity is added, removed, or moved; drift is likely.
  • Troubleshooting becomes harder because a host path problem could be masked by a second view or confused with a duplicate device.
  • Some multipathing stacks may not aggregate paths correctly if the same device appears under two different LUN addresses.

Separate masking views are reasonable when the nodes genuinely need different LUN offsets, when they use different port groups or protocols, or when a regulatory or OS requirement prevents sharing a view. Here, the correct fix is additive zoning: zone both node B HBAs to all four PG_FE_01 ports, activate the zone set, and rescan node B. Keep one masking view unless there is a documented requirement for separate LUN addressing.

3. Give a 30-minute change sequence, including how you add the two new volumes without disrupting node A.

Read the worked answer
  1. Pre-check and record current state: save the zone configuration, confirm MV_APP_PROD composition, and capture node A and node B device and path counts.
  2. Add only the missing zones for node B's two HBAs to the remaining PG_FE_01 ports. Do not remove or modify node A's existing zones.
  3. Activate the zone set during the window and rescan only node B first. Confirm four devices and eight paths in PowerPath, with no duplicate devices.
  4. Add the two new volumes to SG_APP_PROD. Because MV_APP_PROD already maps that storage group, the masking view updates automatically; no new view is needed.
  5. Rescan node B, then node A. Verify each node sees six devices and the expected path count, and check for PowerPath errors or duplicate LUNs.
  6. Rollback plan: if node B does not gain paths, revert the zone activation, rescan, and investigate switch/login state. If adding volumes causes an issue, remove only the new volumes from the storage group after confirming they are not in use.