EMC – VNX Pool LUN Allocation vs Default Owner

Posted on by

I had a question about this come up this week and thought I’d already posted something about it. Seems I was lazy and didn’t. If you have access, have a look at Primus article emc311319 on EMC’s support site. If you don’t, here’s the rough guide to what it’s all about.

When a Storage Pool is created, a large number of private LUNs are bound on all the Pool drives and these are divided up between SP A and B. When a Pool LUN is created, it uses the allocation owner to determine which SP private LUNs should be used to store the Pool LUN slices. If the default and current owner are not the same as the allocation owner, the I/O will have to be passed over the CMI bus between SP, to reach the Pool Private FLARE LUNs. This is a bad thing, and can lead to higher response times and general I/O bottlenecks.

OMG, I might have this issue, what should I do? You can change the default owner of a LUN by accessing the LUN properties in Unisphere. You can also change the default owner of a LUN thusly.

naviseccli -h <SP A or B> chglun -l <metalun> -d owner <0|1>

where

-d owner 0 = SP A
-d owner 1 = SP B

But what if you have too many LUNs where the allocation owner sits on one SP? And when did I start writing blog posts in the form of a series of questions? I don’t know the answer to the latter question. But for the first, the simplest remedy is to create a LUN on the alternate SP and use EMC’s LUN migration tool to get the LUN to the other SP. Finally, to match the current owner of a LUN to the default owner, simply trespass the LUN to the default owner SP.

Note that this is a problem from CX4 arrays through to VNX2 arrays. It does not apply to traditional RAID Group FLARE LUNs though, only Pool LUNs.

3 Comments

  1. It’s a good thing to raise awareness on this issue, although I doubt that your Naviseccli command is going to work.

    chglun only works on Traditional LUNs, not on Pool LUNs.

    You need this:
    naviseccli -h lun -modify -l -sp

    newDefaultSPID can be ‘A’ or ‘B’.

    Source: page 324 in the CLI reference https://support.emc.com/docu47580_VNX-Command-Line-Interface-Reference-for-Block-5.33.pdf?language=en_US

    This applies to both VNX1 and VNX2 series (I’m not sure about the CX4).

  2. Seems like the comment parser doesn’t like greater-than signs. Here is the correct command (I hope it works this time):

    naviseccli -h (SP A or B) lun -modify -l (lunNumber) -sp (newDefaultSPID)

Comments are closed.