This post is more than 5 years old
295 Posts
0
7557
CX4-120 - error event # 71164000 "Description Excessive trespasses detected. Lun: 6006..:861..."
Hello
i am having this error on my CX4-120
any idea
Time Stamp XX/XX/XX XX:XX:XX (GMT) Event Number 71164000
Severity Warning Host B-IMAGE
Storage Array CKMXXXXXXX SP N/A Device N/A
Description Excessive trespasses detected. Lun: 60060160xxxxxxxx:861A9212xxxxxxxx
. Contact Your Service Provider. Run HAVT on the host(s) connected to the LUN in question.
0000040003005600d3040000004016a1004016a1000000000000000000000000000000000000000071164000
kelleg
4.5K Posts
0
November 22nd, 2010 08:00
This can also be called a "trespass storm" - this typically a host configuration issue - Veritas DMP if you're using Solaris, HP-UX PVlinks, ESX and NMP.
You need to find out which host(s) is causing this - in the Event Log you should see messages about trespasses - there should be a disk listed - this is one of the disks in the raid group that contains the LUN(s) that are trespassing. It takes a review of the spcollects to determine which LUN(s) are trespassing.
If you go to "ftp.emc.com/incoming/trespass_report" I have put a program what will help you identify which LUNs are causing the trespassing. To use this program, just run if from the folder where you have a recent spcollects ZIPs - you need both SPA and SPB spcollects in the folder.
glen
driskollt1
131 Posts
1
November 22nd, 2010 07:00
Are you doing any LUN migrations at the moment? If you're doing a bunch, I've seen that pop up before.
If not - What server/os/application are you using? Are you using PowerPath?
Are you using FC, iSCSI, FCoE? How many paths are you using to your array (2, 4, etc)
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
1
November 22nd, 2010 07:00
excessive trespassing is often cause by host failover being incorrectly configured. You need to find out which LUN the WWN points to and what host is using it, then check the failover configuration on the host and the CX4 registration. Creating a Service Request and getting EMC Support to help may be the best approach here
jelucho
295 Posts
0
November 22nd, 2010 08:00
i think that is a vmware esx host 4.1, with ALUA already configured, i am trying to confirm this,
thanks to all
i will get the last spcollect files, then i check the reports.
thank you Glen for the exe file.
i will update my post in a few hours.
mc
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
1
November 22nd, 2010 08:00
Excessive trespasses can be caused because of :-
1. Improper failover mode used by the failover/load balancing software can cause path trashing leading to the LUN trespass storm....most likely.
2. SP issues where in SPs reboot back to back can also cause this situation.....very rare...seen only once in my clariion lifetime.
3. Application setup..... chooses the passive path to send the IOs to the clariion....causing constant trespasses.
4. Check the failover software suggested failover mode on the clariion.....check and see if Failover mode 3 ALUA can be used to alleviate the symptoms.
Leo
kelleg
4.5K Posts
0
November 22nd, 2010 11:00
You might also want to look at Support Solution emc254967 and emc241869 “Where do I find information about using the Navisphere Host Agent for VMware”
glen
christopher_ime
2K Posts
0
November 23rd, 2010 02:00
You mentioned that you were going to gather the host connectivity details and thought it might be ESX 4.1 and ALUA. Could you provide the following:
1) Version of ESX server
Is it 4.1 as you mentioned above?
2) Failover Mode (Navisphere)
If using ALUA, the failover mode would be '4'. Someone above mistakenly mentioned ALUA was a value of '3'.
3) FLARE version
ALUA is only supported with FLARE 04.28.000.5.704 or later
4) Path Selection Plugin?
Round-Robin, MRU, or Fixed?
Also, depending on the combinations above, while this event was triggered (or is this continuous? if so then ignore) was there possibly a reboot of a ESX server in the cluster at the time? Just curious.
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
November 23rd, 2010 06:00
Agreed my bad....ALUA is failover mode 4
Letbetterp
2 Intern
2 Intern
•
196 Posts
0
November 25th, 2010 21:00
Can anyone tell me the name of the program to review spcollects?
RRR
2 Intern
2 Intern
•
5.7K Posts
0
November 26th, 2010 04:00
It's called HEAT and it's not available in a standalone version. you need to upload spcollect zips to powerlink and you'll get a readable html emailed to you.
Home > Support > Product and Diagnostic Tools > Environment Analysis Tools
Letbetterp
2 Intern
2 Intern
•
196 Posts
0
November 27th, 2010 11:00
Ok thanks. We got both san's from dell that is why I can't get to it.
I haft to go through dell for all support.
christopher_ime
2K Posts
0
November 29th, 2010 11:00
Oops... posted within minutes of each other. Kelleg, you basically confirmed what I thought also that there wasn't anything available to end-users. Thanks.
christopher_ime
2K Posts
0
November 29th, 2010 11:00
I am unaware of any end-user utilities to review SP Collects. As EMC employees (and maybe partners?) there are several options of course. So other than opening up the zip and reviewing the files individually there isn't anything available that organizes the output and formats it in a friendly format.
Unless as mentioned by another poster with HEAT (Host Environment Analysis Tools) you were instead inquiring about how to review the output of the EMC Reports or EMC Grab scripts.
kelleg
4.5K Posts
0
November 29th, 2010 11:00
HEAT is used for the "emcreports" or the "host grab". This is for the hosts.
SPcollects are the array logs. Support has a number of tools that we use (CAP2) - basically we unzip the files and look at the status of the errors. The tools we have automate that function somewhat. These are support-only tools.
glen
RRR
2 Intern
2 Intern
•
5.7K Posts
0
November 30th, 2010 01:00
hmmmm, I guess I was totally focussed on something else. SPcollects are indeed not to be read by end users, only by EMC CE and Partners.
EMCGRAB's can be read by using HEAT.
What was I thinking ?