This is going to be an easy answer probably, but have to ask anyways.
(Our storage admin recently left leaving us poking our NetApp filer with sticks to see what hapens since no one else knew anything about it.)
Anyways, we currently have a LUN (windows) mapped to a FCP Intiator group (windows) and everything is working dandy. We now have the need to map an iSCSI intiator group (windows) to this same LUN. But we get an error saying the LUN is already mapped to an FCP group.
Oddly enough we can add our ESX FCP Group and the windows iSCSI group to the LUN without errors, but that doesnt help us.
That lead us to believe that you cant have an FCP and iSCSI group of the same OS mapped to the same LUN.
Anyways, can some one confirm what we think to be true. Or if we are wrong in our assumption, how to get it working?
You can have both iSCSI and FCP igroups for the same LUN. However, you should only map one igroup at a time. Otherwise, you may end up with data corruption. I guess you just want to switch to the iSCSI igroup, correct? If that's the case, you can just unmap the FCP igroup then map the LUN to the iSCSI igroup.
Hope that helps,
Why would there be the posibility of data corrupion? It's just another host accessing a shared lun over a different protocol. If it were another host accessing the same lun over FCP there would be no data corruption possibility right? So, why would introducing an iSCSI host make a difference?
A use case a customer asked for was If they had one fc fabric and they wanted mpio redundancy with fcp and Ethernet as a passive path. I don't like it but if budgets only allow few fc ports I could see trying it.
Sent from my iPhone 4S
Hi Kyle. Yes you can certainly map a LUN to multiple igroups. In this example I created a LUN called lun0 in /vol/marty and mapped it to a FC igroup called marty1 and an iSCSI igroup called marty2. Please see below.
argon> lun show -v /vol/marty/lun0
/vol/marty/lun0 1.0g (1077511680) (r/w, online, mapped)
Space Reservation: disabled
Multiprotocol Type: windows
Maps: marty1=0 marty2=0
Occupied Size: 0 (0)
Creation Time: Thu Oct 20 14:55:46 EST 2011
Cluster Shared Volume Information: 0x0
argon> igroup show -v marty1
OS Type: windows
Member: 01:02:03:04:05:06:07:08 (not logged in)
argon> igroup show -v marty2
OS Type: windows
Member: iqn.1991-05.com.microsoft:marty (not logged in)
If you'd like more help, perhaps you could share your syntax/output.
I found this post with google - searching for a storage which can handle both "presentations" - over FC and over iSCSI.
We have one server-room with two ESX-Servers and the storage - and another one with a signle ESX-Machine. The "offsite" location is connected with a MULTIMODE fibre-cable (about 500 meters). I heared, that FC over this distance is not recommended - and therefore I want to use iSCSI (1GBit) to connect the machine to the storage. Also our budget is a little bit to small to get HBA or any kind of single-mode cables.
Do you think, that this is a good solution?
Another question about the above mentioned solution:
I found another thread in this forum with the title iSCSI and FC presenting the same lun. (http://communities.netapp.com/thread/14775) They explained that there is a difference when the storage is in Cluster-Mode or in NON-ClusterMode.
Marty - does your solution depend on Cluster-mode and NON-Cluster Mode ?
Thand you in advance
500m is the “official” distance where FC with 1Gb/s and OM2 cable (the one used at the time FC was initially deployed) should work. The real limit is determined not by distance as such, but by signal attenuation which is factor of cable quality, number of connectors, SFP/GBIC sensitivity etc. In real life distance may be better or worse.
You could try to use FC and monitor for errors. Even better would be to hire somebody to measure signal loss. Here is NetApp document describing some considerations about FC distance: http://now.netapp.com/NOW/knowledge/docs/san/guides/CFO_cable/cabledistance.shtml
Command not showing UUID? What may be reason? & how to get UUID for respective node?
igroup show -v lhrmdst1
OS Type: linux
Member: iqn.1999-11.com.agilent.cos.lhrmdst1 (logged in on: vif1-66)