Presenting the LUNs is done at the storage side. This part of your question might get a better answer from the Storage section of these forums, but usually, you find the WWN(s) of the FibreChannel HBA(s) on your server and configure the storage system to "present this vdisk to these WWNs". I understand this is known as "masking" in the FibreChannel terminology.
If you use EVA CommandView, you can probably first add all the server's WWNs to the CommandView as a "Host" object, then you can use the Host object to present the vdisk(s) to the server as a single operation, even if the server has many HBAs.
There are probably also parameters that identify the type of the host (Linux/Windows/HP-UX 11.31+/HP-UX older/ etc...) or the FC/SCSI features understood by the host, so that the storage's behavior can be tailored to match the capabilities of the host OS. Be sure to set these parameters correctly.
If you have SAN switches, you may also want to configure them, to make sure the server uses sensible paths through your SAN fabric and does not see any devices it isn't supposed to see. I understand this is known as "zoning". I don't know anything about this part, so if you need help in this, you'll have to read your SAN switch documentation or find a storage expert to help you.
After the masking and zoning steps (if necessary) are correctly done, the Linux OS should simply auto-detect the new LUNs as /dev/sd* devices as it boots up. Newer distributions (RHEL 5 and newer) should be able to detect new LUNs automatically even without rebooting; however, this mechanism is not yet perfect and may require manual re-scanning.
See RedHat's Online Storage Reconfiguration Guide:
https://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/html/Online_Storage_Reconfiguration_Guide/index.htmlIt is nominally written for RHEL 5, but the procedures in it should be usable (perhaps with minor changes) in most modern Linux distributions that use a 2.6.* series kernel.
After the LUNs are visible as /dev/sd* devices, the next steps are essentially "do whatever you want/need with them". But usually, if you have more than one HBA or your SAN fabric otherwise presents multiple paths to your LUNs (i.e. you see 2 or more /dev/sd* devices for each LUN), the first step is to implement a multipath solution.
Currently, RedHat's recommendation is to use "device-mapper-multipath", the generic mechanism built in the Linux kernel:
https://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.5/html/DM_Multipath/index.htmlYou may also use the storage manufacturer's proprietary multipath software, if you wish and one is available for your OS version.
After that, it really depends on your environment and what you wish to use your LUNs for. You can set up a traditional PC partition table on the LUNs if you want and use them like regular SCSI disks.
If you want to create filesystem(s), the use of LVM is recommended: that would make the on-line management and expansion of those filesystems *much* easier.
If you're unfamiliar with LVM, see RedHat's LVM Administration Guide for an introduction:
https://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.5/html/Logical_Volume_Manager_Administration/index.htmlIn a mixed Linux/Windows environment, the creation of a traditional PC partition table is usually recommended even if you plan to use LVM. If someone ever makes a mistake in the SAN configuration and presents a Linux LUN to a Windows system, the existence of a partition table indicates to the Windows system that the LUN is already in use, so the "easy and automatic" Windows systems won't overwrite it. If you want to do this, just use fdisk or cfdisk to create a partition that covers the entire LUN, and set its type to "Linux" (83) or "Linux LVM" (8e) as appropriate, then use that partition as a LVM physical volume.
If you're using the LUNs for Oracle databases, you might want to use ASM directly on top of the multipath solution.
MK
MK
