VNX Pool LUN default owner changed by itself (multiple)

Hi EIThoro

The only way to change default owner is to migrate the LUN (create the new LUN on the right SP, and select migrate on the context menu of your LUN to change).

I never heard about default owner change too !!!

Do you have MirrorView? If yes, it is because remote LUN are not on the same SP. Use migrate fonctionality to change default owner.

regards.

Pascal

Is dedup enabled on these luns?

"The first lun added for dedup will determine the SP for the dedup container for a given pool by looking at that LUNs allocation owner. Any LUNs migrated will have their allocationowner changed to the dedup container SP owner. But the default and current owners will be unchanged for that newLUN New LUNs will have their allocation owner = dedup container owner and you need to manually select the DefaultOwner to match the dedup container SP owner. "

Re: Question on VNX2 block Deduplication

In Flare 30-32 (CX4 and VNX1) the Default SP owner on a Pool LUN can only be changed manually. If the Default SP owner does not match the Allocated SP owner, then it was manually changed. There is a log entry when this happens (naviseccli -h IP_Address_SPA getlog). Note that the IP address in the output will be the PC that ran the command to change the default owner

07/07/2015 11:52:46 N/A                  (4600)'SetDefaultOwner' called by ' Navi User administrator' (xx.xxx.92.63) on 'Pool LUN : Glen-Test-Default-SP ' (Result: Success).

When you change the Default SP owner you also get a warning popup:

In Flare 33 (VNX2), if you use Deduplication, when a LUN is added to a Deduiplication Container (enable Deduplication on the LUN), if the Allocated/Default SP owner does not match that of the Deduplication Container, then the Allocated SP owner will be changed and you must then manually change the default SP owner to match the new Allocated SP owner. This is the only time that the Default SP owner could be changed by the array.

glen

I checked on a few other VNX2 (FLARE 32) in my organization and they are experiencing the same problem. Some have lesser numbers of mismatch LUNS (30/400). But I have verified with the administrators that nobody has manually changed the default owner).

Below is how the LUN properties are showing.

As for Deduplication, we do not have the dedupe enabler installer/unlicensed.

The EMC TAM for my account has brought this up with EMC engineering. Let's see what they think.

Well VNX2 series runs MCx R33 (sometimes referred to as Flare33) which introduced block deduplication.  On the VNX1 series (like your 7500) this feature isn't even available, so surely isn't the culprit.

In my work I've dealt with a LOT of VNX frames in a LOT of environments, and I can say I have never seen the default owner arbitrarily change.

While it is possible that someone in your environment changed it, or you have some "thing" in your environment that changed it, those are pretty unlikely.  I would say it is also pretty unlikely that you have a bug that is causing multiple arrays to change default ownership, although feel free to engage EMC engineering. 

What is more likely is that someone performed LUN migrations but did not complete the process.  For the image above, it looks like someone started out with a LUN owned (current/allocation/default) by SPA, and migrated it to a LUN owned (current/allocation/default) by SPB.  You can test this yourself by creating a tiny LUN on SPA and SPB and then doing a LUN migration for the SPA LUN to SPB.

What you'll end up with is exactly what you indicate in your image.  A LUN whose current owner and default owner are SPA, but allocation owner is SPB.   To complete the LUN migration, you should trespass the LUN (corrects Current owner) and then manually swap Default Owner.

If you don't finish the steps out, the LUN will remain mismatched as you indicate. 

You can also avoid this entirely by ensuring that your migration target is on the same SP as your source, unless (obviously) you are trying to correct something like an SP utilization imbalance.