Tag Archives: mirrorview

EMC – naviseccli – checking your iSCSI ports are running at the correct speed

Posted on by

It’s been a while since I wrote about naviseccli and I admit I’ve missed it. I once wrote about using naviseccli to identify MirrorView ports on a CLARiiON array. Normally the MirrorView port is consistently located, but in that example we’d upgraded from a CX3-80 to a Cx4-960 and it was in a different spot. Oh how we laughed when we realised what the problem was. Anyway, we’ve been doing some work on an ever so slightly more modern VNX5300 and needed to confirm that some newly installed iSCSI SLICs were operating at the correct speed. (Note that these commands were run from the Control Station).

The first step is to list the ports

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.09.07 08:59:37 =~=~=~=~=~=~=~=~=~=~=~=
[nasadmin@NAS001 ~]$ navicli -h A_VNXSP connection -getport

SP:  A
Port ID:  8
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a8
iSCSI Alias:  0017.a8
IP Address:  192.168.0.13
Subnet Mask:  255.255.255.0
Gateway Address:  192.168.0.254
Initiator Authentication:  false

SP:  A
Port ID:  9
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a9
iSCSI Alias:  0017.a9

SP:  A
Port ID:  10
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a10
iSCSI Alias:  017.a10

SP:  A
Port ID:  11
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a11
iSCSI Alias:  017.a11

SP:  B
Port ID:  8
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b8
iSCSI Alias:  0017.b8
IP Address:  192.168.0.14
Subnet Mask:  255.255.255.0
Gateway Address:  192.168.0.254
Initiator Authentication:  false

SP:  B
Port ID:  9
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b9
iSCSI Alias:  0017.b9

SP:  B
Port ID:  10
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b10
iSCSI Alias:  017.b10

SP:  B
Port ID:  11
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b11
iSCSI Alias:  017.b11

Once you’ve done that, you can list the port speed for a particular port

[nasadmin@NAS001 ~]$ navicli -h A_VNXSP connection -getport -sp a -portid 8 -speed
SP:  A
Port ID:  8
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a8
iSCSI Alias:  0017.a8
IP Address:  192.168.0.13
Subnet Mask:  255.255.255.0
Gateway Address:  192.168.0.254
Initiator Authentication:  false
Port Speed:  1000 Mb
Auto-Negotiate:  Yes
Available Speeds:  10 Mb
-               :  100 Mb
-               :  1000 Mb
-               :  Auto

If you have a lot of ports to check this may not be the most efficient way to do it (ioportconfig may be more sensible), but if your network team are reporting on one particular port being an issue – this is a great way to narrow it down.

EMC – Some new scripts

Posted on by

Mat has come up with a few new scripts – FlipFASTTiering and ReplicationCapacity. They’re PERL scripts that you can use to list / modify FAST Tiering scheduling and report on MirrorView replication data respectively. Hopefully you’ll find them of some use. Further information can be found on the Utilities page.

EMC – MirrorView Secondary Image States

Posted on by

I sometimes get asked what the definition of these states is, and I frequently have trouble defining it clearly. Fortunately, EMC’s MirrorView Knowledgebook has been updated to incorporate Release 32, and Appendix A has some succinct definitions. If you can’t be bothered looking them up for yourself, here they are.

  • Synchronized – The secondary image is identical to the primary. This state persists only until the next write to the primary image, at which time the image state becomes Consistent.
  • Consistent – The secondary image is identical to either the current primary image or to some previous instance of the primary image. This means that the secondary image is available for recovery when you promote it.
  • Synchronizing – The software is applying changes to the secondary image to mirror the primary image, but the current contents of the secondary are not known and are not usable for recovery.
  • Out-of-Sync – The secondary image requires synchronization with the primary image. The image is unusable for recovery.
  • Rolling Back (MV/A only) – A successful promotion occurred where there was an unfinished update to the secondary image. This state persists until the Rollback operation completes.

I think one of the key things here is to pay attention to the various image states, particularly if you’re seeing a lot of out-of sync states on your secondaries. You don’t want to have to explain to people why they can’t recover secondaries in the event of a serious failure. And, more importantly, get on Powerlink and check out the MirrorView Knowledgebook (H2417).

EMC – Manipulating the Write Intent Log LUNs with naviseccli

Posted on by

Last week Mat was wanting to migrate some WIL LUNs on one of our CX4s to a different RAID Group. Unfortunately, one does not simply migrate WIL LUNs. Firstly, once they’re allocated, they’re treated as Private LUNs by FLARE, so you can’t use Virtual LUN technology to migrate them. Secondly, if you have active MirrorView mirrors in place, you’ll get the following error when trying to de-allocate the WIL LUNs via Unisphere: “Unable to deallocate WIL since in use (0x71058199)[0x71058199]“. Note that fracturing the mirrors is not sufficient to avoid this error.

So there’s a few things you need to do to resolve this. Firstly, confirm the WIL LUNs in use on the array (there’s only 2).

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -listlog
Storage Processor: SP A
Lun Number: 10000
Storage Processor: SP B
Lun Number: 10001

Now list all the mirrors that are using the WIL. Note that it lists the primary and secondary mirrors, so you’ll need to extraxt the primary mirrors from the list.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -list -usewriteintentlog
MirrorView Name: DC1_FC_R5_DATA_0002_SRM
Write Intent Log Used: YES
[snip]

Now the simplest thing to do is create a script that runs the command below for each of the mirrors in your list of primaries. This command disable the use of the WIL, and -o won’t prompt for confirmation.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -change -name DC1_FC_R5_DATA_0002_SRM -usewriteintentlog no -o

Now that you’ve done that, you can allocate the new WIL LUNs.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -allocatelog -spA lun_ID1 -spB lun_ID2

Now run your script again, changing -usewriteintentlog from no to yes.

naviseccli -user User_ID -scope 0 -password xxxxxxxx -h 1.1.1.1 mirror -sync -change -name DC1_FC_R5_DATA_0002_SRM -usewriteintentlog yes -o

And now you can get rid of those old WIL LUNs. Huzzah!

EMC – Configure the Reserved LUN Pool with naviseccli

Posted on by

I’ve been rebuilding our lab CLARiiONs recently, and wanted to configure the Reserved LUN Pool (RLP) for use with SnapView and MirrorView/Asynchronous. Since I spent approximately 8 days per week in Unisphere recently performing storage provisioning, I’ve since made it a goal of mine to never, ever have to log in to Unisphere to do anything again. While this may be unattainable, you can get an awful lot done with a combination of Microsoft Excel, Notepad and naviseccli.

So I needed to configure a Reserved LUN Pool for use with MV/A, SnapView Incremental SAN Copy, and so forth. I won’t go into the reasons for what I’ve created, but let’s just say I needed to create about 50 LUNs and give them each a label. Here’s what I did:

Firstly, I created a RAID Group with an ID of 1 using disks 5 – 9 in the first enclosure.

C:\>naviseccli -h 256.256.256.256 createrg 1 0_0_5 0_0_6 0_0_7 0_0_8 0_0_9

It was then necessary to bind a series of 20GB LUNs to use, 25 for each SP. If you’re smart with Excel you can set the following command to do this for you with little fuss.

C:\>naviseccli -h 256.256.256.256  bind r5 50 -rg 1 -aa 0 -cap 20 -sp a -sq gb  

Here I’ve specified the raid-type (r5), the lun id (50), the RAID Group (1),  -aa 0 (disabling auto-assign), -cap (the capacity), -sp (a or b), and the -sq (size qualifier, which can be mb|gb|tb|sc|bc). Note that if you don’t specify the LUN ID, it will automatically use the next available ID.

So now I’ve bound the LUNs, I can use another command to give them a label that corresponds with our naming standard (using our old friend chglun):

C:\>naviseccli -h 256.256.256.256 chglun -l 50 -name TESTLAB1_RLP01_0050

Once you’ve created the LUNs you require, you can then add them to the Reserved LUN Pool with the reserved command.

C:\>naviseccli -h 256.256.256.256 reserved -lunpool -addlun 99

To check that everything’s in order, use the -list switch to get an output of the current RLP configuration.

C:\>naviseccli -h 256.256.256.256 reserved -lunpool -list
Name of the SP:  GLOBAL
Total Number of LUNs in Pool:  50
Number of Unallocated LUNs in Pool:  50
Unallocated LUNs:  53, 63, 98, 78, 71, 56, 88, 69, 92, 54, 99, 79, 72, 58, 81, 5
7, 85, 93, 61, 96, 67, 76, 86, 64, 50, 66, 52, 62, 68, 77, 89, 70, 55, 65, 91, 8
0, 73, 59, 82, 90, 94, 84, 97, 74, 60, 83, 95, 75, 87, 51
Total size in GB:  999.975586
Unallocated size in GB:  999.975586
Used LUN Pool in GB:  0
% Used of LUN Pool:  0
Chunk size in disk blocks:  128
No LUN in LUN Pool associated with target LUN.
C:\>

If, for some reason, you want to remove a LUN from the RLP, and it isn’t currently in use by one of the layered applications, you can use the -rmlun switch.

C:\>naviseccli -h 256.256.256.256 reserved -lunpool -rmlun 99 -o

If you omit the override [-o] option, the CLI prompts for confirmation before removing the LUN from reserved LUN pool. It’s possible to argue that, with the ability to create multiple LUNs from Unisphere, it might be simpler to not worry about naviseccli, but I think that it’s a very efficient way to get things done quickly, particularly if you’re working in a Unisphere domain with a large number of CLARiiONs, or on a workstation that has some internet browser “issues”.

EMC – getting the status of MirrorView operations with naviseccli

Posted on by


 Tired of sifting through a Consistency Group to see the status of MirrorView synchronizations? Tire no more with the mirror -sync -listsyncprogress command!

c:\>naviseccli -address 256.256.256.256 mirror -sync -listsyncprogress

MirrorView Name:  MIRROR_FC_R5_DAT02_0030_SRM
Has Secondary Images:  YES
Image UID:  50:06:01:60:BB:20:36:C1
Image State:  Synchronizing
Synchronizing Progress(%):  97

MirrorView Name:  MIRROR_FC_R5_MNT01_0042_SRM
Has Secondary Images:  YES
Image UID:  50:06:01:60:BB:20:36:C1
Image State:  Synchronized
Synchronizing Progress(%):  100

MirrorView Name:  MIRROR_FC_R5_DAT04_0046_SRM
Has Secondary Images:  YES
Image UID:  50:06:01:60:BB:20:36:C1
Image State:  Synchronizing
Synchronizing Progress(%):  72

MirrorView Name:  MIRROR_EFD_R5_MSMQ01_0055_SRM
Has Secondary Images:  YES
Image UID:  50:06:01:60:BB:20:36:C1
Image State:  Synchronized
Synchronizing Progress(%):  100

EMC – naviseccli – how to identify the MirrorView ports

Posted on by

With the introduction of Flexports the location of the MirrorView front-end port is not always the last port on the SP. Sometimes you’ll find it quicker to identify the MirrorView port through the use of naviseccli. Here’s how to do it.

If you don’t have the MirrorView enabler installed on the array, but want to keep the port aside for when you do, use the ioportconfig command to identify any ports marked as Special in Port Usage – these ones are MirrorView ports.

C:\>naviseccli -h 256.256.256.256 ioportconfig -list > c:\tmp\array_ports.txt

SP ID:   A
I/O Module Slot:   1
I/O Module Type:   Fibre Channel
I/O Module State:   Present
I/O Module Substate:   Good
I/O Module Power state:   On
I/O Carrier:   No

Information about each port on this I/O module: 
Physical Port ID:   0
Port Role:   BE
Logical Port ID:   2
Port Usage:   Normal
Port Type:   Fibre Channel
Port State:   Enabled
Port Substate:   Good
Is Persisted:   Yes

Physical Port ID:   1
Port Role:   BE
Logical Port ID:   3
Port Usage:   Normal
Port Type:   Fibre Channel
Port State:   Enabled
Port Substate:   Good
Is Persisted:   Yes

Physical Port ID:   2
Port Role:   FE
Logical Port ID:   2
Port Usage:   Normal
Port Type:   Fibre Channel
Port State:   Enabled
Port Substate:   Good
Is Persisted:   Yes

Physical Port ID:   3
Port Role:   FE
Logical Port ID:   3
Port Usage:   Special
Port Type:   Fibre Channel
Port State:   Enabled
Port Substate:   Good
Is Persisted:   Yes

If you have the MirrorView enabler installed the port command is all you need. This is a handy command with some pretty verbose output, and provides information on the total number of attached initiators, amongst other things.

C:\>naviseccli -h 256.256.256.256 port -list -sp -all > c:\tmp\array_port_list.txt

[snip]

SP Name:             SP B
SP Port ID:          3
SP UID:              50:06:01:60:BB:20:36:C1:50:06:01:6B:3B:20:36:C1
Link Status:         Up
Port Status:         Online
Switch Present:      YES
Switch UID:          20:09:00:0D:EC:5A:FA:81:20:CB:00:0D:EC:5A:FA:80
SP Source ID:        852207
ALPA Value:         0
Speed Value :         4Gbps
Auto Negotiable :     NO
Available Speeds:    
1Gbps
2Gbps
4Gbps
Auto
Requested Value:      Auto
MAC Address:         Not Applicable
SFP State:           Online
Reads:               0
Writes:              641452077
Blocks Read:         0
Blocks Written:      3126242880
Queue Full/Busy:     0
I/O Module Slot:     1
Physical Port ID:    3
Usage:     Mirrorview

Of course you can always look at the ports in Unisphere – check out an old post I did a little while ago for information on how to do that.

VMware – SRM advanced setting for snap prefix

Posted on by

We haven’t been doing this in our production configurations, but if you want to change the behaviour of SRM with regards to the “snap-xxx” prefix on replica datastores, you need to modify an advanced setting in SRM. So, go to the vSphere client – SRM, and right-click on Site Recovery and select Advanced Settings. Under SanProvider, there’s an option called “SanProvider.fixRecoveredDatastoreNames” with a little checkbox that needs to be ticked to prevent the recovered datastores being renamed with the unsightly prefix.

You can also do this when manually mounting snapshots or mirrors with the help of the esxcfg-volume command – but that’s a story for another time.

EMC MirrorView – New Article

Posted on by

I wrote a brief article on configuring EMC MirrorView from scratch through to being ready for VMware SRM usage. It’s not really from scratch, because I don’t go through the steps required to load the MirrorView enabler on the frame. But I figured that’s more a CE-type activity in any case. I hope to follow it up with a brief article on the SRM side of things. You can find my other articles here. Enjoy!

CX4 I/O Modules and MirrorView

Posted on by

When the CX4 was released some time ago, I sat through on-line training and learnt about the differences between the CX3 and CX4. One of the big things for the CX4 was the introduction of I/O modules that enabled you to scale out front-end performance for the array. But, like any training I’ve undertaken, I filed away the information about how they work in the real world and forgot all about it.

So when we went to test MV/S connectivity between our two 960 arrays, we had some connectivity issues. When we went to establish a MirrorView connection, this is what we got on the first array.

On the second array, it looked like this.

Not so cool. But the boneheaded thing I’d forgotten from my CX4 What’s New training was that, when an array is first initialised, the MirrorView ports are assigned to the last port. If you add I/O modules after the fact, those MV ports don’t change.  So while one of the array’s was a new CX4-960, the other was an upgraded CX3-40f, which had different ports when it was upgraded. Here are some pictures that serve to illustrate my words.

You’ll notice that on the second array the MirrorView ports are A1 and B1, not A3 and B3.

And finally, it’s important to respect the zoning rules with MirrorView – something my colleague didn’t understand when he had B1 zoned to A3, and so forth. Good times.