This post is more than 5 years old
2 Intern
•
614 Posts
0
1199
November 3rd, 2010 12:00
fabric manager, syminq no longer working
Hi,
I have a server zoned to the dmx. A DBA wanted some tier -2 storage(clariion) for a temporary installation mount point since the root drive in the blade is maxed out. I zoned it up in fabric manager, activated the zone set, and when I exited out of fm, i was asked to save my configuration changes to the switch. I hit cancel instead and now syminq does not work. I get an error that lost communication with base daemon. Oracle RAC is running on the raw devices zoned up from the dmx. What should I do to get syminq working and should I just go back into fabric manager(the zones are there) and exit out again to see if I get prompted?
Thanks in advance!
No Events found!
Boom1
131 Posts
0
November 3rd, 2010 14:00
Run following command on switch..
show zoneset active vsan xxx
make sure your zone are active..
you can do online lun scanning for gatekeeper device.
run symcfg discover.
dynamox
9 Legend
•
20.4K Posts
0
November 3rd, 2010 14:00
the minute you hit activate, your zone set got activated ..the prompt that you got at the end simply saves running config to startup config. I don't believe that was what caused syminq to stop working. Can you try inq ?
ftp://ftp.emc.com/pub/symm3000/inquiry/
admingirl
2 Intern
•
614 Posts
0
November 3rd, 2010 19:00
Thank you so much! That is correct the zone is active and I could define a storage group for it on the clariion. Here is what is happening, just for an experiment, I deleted the zones and left only the original zone to the dmx. After removing the zones, the syminq starts working again. It's version 6.4.0. So I redefined the zones, this time I exited out of fm properly and low and behold, syminq freask out again. I should be able to zone a host to two different storage types, dmx, and clariion so I do not know why syminq flakes out.
dynamox
9 Legend
•
20.4K Posts
0
November 3rd, 2010 20:00
by the way ..what OS is this ?
dynamox
9 Legend
•
20.4K Posts
0
November 3rd, 2010 20:00
did you try regular inq from the link above ?
admingirl
2 Intern
•
614 Posts
0
November 3rd, 2010 22:00
Linux 5.3
admingirl
2 Intern
•
614 Posts
0
November 3rd, 2010 23:00
Just to clarify, it shows two devices for DCG(probably clarrion), however, I have not mapped/provisioned any luns for it yet, I have only zoned it and created a storage group. The version of solutions enabler stuff is 6.4.0 on ther server.
admingirl
2 Intern
•
614 Posts
0
November 3rd, 2010 23:00
yes, it works, however, I get a segmentation fault at the end.
Nollaig1
1 Rookie
•
137 Posts
0
November 4th, 2010 04:00
Hello,
Would it be possible to get the actual error message from the symapi log file?
Thank you,
Nollaig
dynamox
9 Legend
•
20.4K Posts
1
November 4th, 2010 04:00
i really think it's choking on LUNZ ..which is a ghost device until you present the first LUN to the storage group.
dynamox
9 Legend
•
20.4K Posts
0
November 4th, 2010 04:00
on Clariion, did you manually register the host in Connectivity Status or you have a navi agent running ? Did you also put the host into a storage group but there are no LUNs right ?
admingirl
2 Intern
•
614 Posts
0
November 4th, 2010 06:00
It seems the common practice on the cx4-480 is to just manually register the hba and then create the storage group without using the agent. I will bind a lun to the group and see what happens.
Nollaig1
1 Rookie
•
137 Posts
1
November 4th, 2010 08:00
Hello Admingirl,
Just a few other thoughts as well. From the connectivity guide, (sorry for stating the obvious) zoning guidelines:
A single zone should not contain multiple initiator ports.
Multiple target ports from multiple arrays are supported in a single zone.
Im with Dynamox on this one, what happens when you assign a Lun?
Nollaig
admingirl
2 Intern
•
614 Posts
0
November 4th, 2010 09:00
The lun shows up as it should with two paths, raid-5 however, I still get a segmentation fault when running inq and syminq still hangs.
dynamox
9 Legend
•
20.4K Posts
1
November 4th, 2010 11:00
can you look in /var/symapi/log/symapi-20101104.log around the time you ran syminq ...anything jumps out at you ?