05-27-2011 03:44 AM
I've got a few problems mounting a LUN on a remote server (CentOS 5.5, based on RHEL 5.5).
The server is connected through a Brocade HBA 415 and can see the remote ports correctly. I can even log into HCM Agent and see the LUN in the end of the tree.
The thing is that I cannot see a mounting point in the OS and cannot fdisk it (it displays "I don't know how to handle files with mode 2180" when trying to "fdisk /dev/bfa"). I know I have to format the disk prior to mount it (of course), but I don't know where the remote drive is located.
The modprobe.conf has
options bfa host_name="host123" os_name="CentOS release 5.5 (Final)"
alias scsi_hostadapter_brcd_bfa bfa
The "lsscsi" says:
cd/dvd hp DVD A DS8A5LH 1HE3 /dev/scd0
storage EMC SYMMETRIX 5771 -
so, in fact, there is no mounting point.
I've installed also multipath and is running, but I don't know if I'm doing something wrong with it, because it displays ("multipath -v3"):
cciss!c0d0: not found in pathvec
cciss!c0d0: mask = 0x1f
/etc/multipath.conf has the blacklisted part commented out.
The firmware es 18.104.22.168 and is working properly.
I'm having these problems for a little bit long, so I'm in the need of a solution!
Thanks in advance!
05-27-2011 04:43 AM
If it helps, here is a little bit more of information related to the volumes and disks:
/dev/cciss/c0d0p1 * 1 13 104391 83 Linux
/dev/cciss/c0d0p2 14 60794 488223382+ 8e Linux LVM
PV /dev/cciss/c0d0p2 VG VolGroup00 lvm2
Total: 1 / in use: 1 / in no VG: 0
05-27-2011 05:48 AM
If i'm not mistaken /dev/cciss is usually found when using an HP/Compaq RAID controller.
Did you run an insf to create device files for your EMC LUN.
Did you provisioned (Mapped and Masked) a symm device to you host.
Running fdisk /dev/bfa looks more like you were trying to format the FCHBA.
05-27-2011 08:10 AM
In fact, the cciss is the HD RAID. It has been created with the controller board, so the Linux didn't care.
I cannot run infs because the system is a CentOS, not a HP-UX. I've looked for the app, but no luck.
The hardware and config after the HBA is out of my control and supposed correct. I've launched the question so the config can be checked once again.
Is there any other tool to tell the OS to refresh the devices? The box has been rebooted many times before and it does not update anything by itself...
05-30-2011 02:19 AM
The storage team has checked the status of the association, and they say it's correct:
Symmetrix ID : 000000SYMMID000
Originator Port wwn : 1000000123456789
User-generated Name : 1000000123456789/1000000123456789
Sym Dev LUN
Name Dir:P Physical Device Name VBUS TID SYMM HOST Attr Cap(MB)
------ ----- ----------------------- ---- --- ---- ---- ---- -------
16C7 9B:1 Not Visible 0 0 2 N/A (M) 1028259
Although I still cannot see the volume in the system. Should it be available directly? The ECC agent is installed and running, but I'm not sure if it is needed anyway (there will be a single volume and a single path!).
05-30-2011 09:12 AM
You don't need the ECC agents in order to see the LUN(S),but since you have, can't you look in ECC where the LUN attaches to your system.
Path details or relationships pane's are able to display this.
On the system you should have tools to qury your HBA but i'm not familiar with them.
06-01-2011 12:05 AM
I have multiple tools for reviewing the system status (lsscsi, bcu and so on).
I have verified that the system sees the LUN (through HCM Agent on a remote computer and through bcu). The thing is that a SCSI generic device is created succesfully (/dev/sg1) but no block device is understood after it. I don't know if there should be a specific driver installed or something. The Brocade driver + tools are correctly and fully installed (as stated in the documentation).
I understand that now that the system talks to the HBA and the kernel understands there is a SCSI device with a data stream (sg1) on the system, it should create the block device automagically.
I've tried the "sg3 utils" so I could map it manually, but they seem to be a little bit specific for me and find out they're not so useful at last.
The kernel messages ("dmesg") tell me the device is ok and everything is working, but compared to USB pendrive, the block device is never created.
I reinstalled the system to verify there is no driver overlapping, but behaves the same...