While looking for something totally different I stumbled on a few new Unity XT (?) model numbers.
On this dellemc.com website I spotted some Chinese publication on this new model.
[edit] The new and working website is now working: www.dellemc.com.
While looking for something totally different I stumbled on a few new Unity XT (?) model numbers.
On this dellemc.com website I spotted some Chinese publication on this new model.
[edit] The new and working website is now working: www.dellemc.com.
Checking the environment of a switch:
Checking for errors and signal degradation
Common knowledges dictates that fiber optice patches need to be cleaned with proper equipment to prevent unnecessary signal loss. See this blog post for more details on how and why to keep optic cables clean.
LUN-replication on Unity works slightly different than it previously did on VNX or even Clariion. In these older generations, when you deleted the mirrorview Mirror Group, both the primary and secondary LUNs became usable as separate entities.
In Unity the secondary LUN is a different beast. First of all: in Unity you can only set up replication from the primary Unity/LUN. The process on the source-Unity will create a LUN-replica and a replication session on both Unitys.
But what happens when you need hosts to access the secondary LUN? A failover works as designed and the previous secondary LUN becomes writable, but when you break the replication session, the replica-LUN has a flag that needs to be reset, but you’ll need the CLI to do that. This is how I did it:
Once in a while you come across a storage system that cannot be managed through the GUI or you just want to script or use the CLI to perform management tasks on a VNX. Recently I came across an old VNX2 which GUI wasn’t responding the way I’d like, so I decided to use the CLI instead.
In this particular case I needed to expand a LUN.
First I listed the current size:
naviseccli -h [SPA/B ip#] -user [user] -password [password] -scope [scope] getlun [LUN#]
Then I expanded the LUN to the new size:
naviseccli -h [SPA/B ip#] -user [user] -password [password] -scope [scope] lun -expand -l [LUN#] -capacity [new capacity] -sq [mb/gb/tb/bc]
Pay attention to the number and the prefix! It could be a lot of work if you needed to resize a LUN from 50GB to 60GB and instead GB, you used TB…..
And finally I checked if the new size was actually available:
naviseccli -h [SPA/B ip#] -user [user] -password [password] -scope [scope] getlun [LUN#]
Sometimes CLI is so much easier than the GUI!
When decommissioning a VNX, I recently forgot to remove the array from the existing domain. After the VNX was “unracked and unstacked” I saw my mistake and tried to remove it from the domain by using the “add/remove systems” in Unisphere, but the remove-button was grayed out. Even engineering mode didn’t help me.
There is another way to remove unwanted VNXs from a domain! You might have guessed it already, because it’s by using the command line!
First you’ll have to find out what existing VNX is the domain master. This can be done in Unisphere by looking up the current master. Click on “Domains” followed by “Select Domain Master”.
The outcome will show you the list of domain in the domain as well as the current master.
Now you can open a command line box and enter the following command to deleted the unwanted VNX from the domain:
naviseccli -Address -User -Password -Scope 2 domain -remove
Follow me on social media