#iSCSI LUN's has been assigned to wrong hosts.

1 messages · Page 1 of 1 (latest)

lean linden
#

I have two LUN's called 4c6b and 4c6c by LUN serial numbers or /vol/cc_esxi069_vol/lun_cc_esxi069 and /vol/cc_esxi070_vol/lun_cc_esxi070 by lun names.

On the cluster ontap. 4c6b has been assigned to ESXi host 069, and 4c6c has been assigned to ESXi host 070. However, the problem is, from vSphere GUI, somehow now 4c6b is being used by the host 070 and already in the production. What is the best way to fix it. 4c6b seems also in use by 069 but with Errors which means it is not really correctly used.

Can we let 070 to continue to use 4c6b, and reassign 4c6c to 069? Do we have to have a downtime for this change?

languid crescent
#

The cleanest way would be to unmount them.

#

Or you could just rename them and leave it if it's not causing any harm and is functional.

fresh tapir
#

Have you mapped the LUNs to different igroups?
Are the IQNs of the two ESXi hosts unique?

#

What do you want to do with these tiny LUNs? Use them for VMFS? Or for SAN boot?

lean linden
#

They both for SAN boot

#

4c6b has already had data for host 070

#

they are two diffent hosts, and with unique IQN number

cobalt trout
#

if it is just a rename...then do it. LUNs should not be mounted in ontap anyplace (the volume hosting the lun should not be mounted in the namespace...only NAS volumes)

You can rename the volume
vol rename -vserver xxx -volume cc_esxi069_vol temp70
vol rename -vserver xx -volume cc_esxi070_vol cc_esxi069_vol
vol rename -vserver xxx -volume temp70 cc_esxi070_vol)

then rename the LUNs
lun move-in-volume -vserver xxx -volume cc_esxi070_vol -lun lun_cc_esxi069 lun_cc_esxi070x
lun move-in-volume -vserver xxx -volume cc_esxi069_vol -lun lun_cc_esxi070 lun_cc_esxi069x
lun move-in-volume -vserver xxx -volume cc_esxi070_vol -lun lun_cc_esxi070x lun_cc_esxi070
lun move-in-volume -vserver xxx -volume cc_esxi069_vol -lun lun_cc_esxi069x lun_cc_esxi069

lean linden
#

I did remapping:
50 lun mapping delete -vserver eos-iscsi-1 -path /vol/cc_esxi070_vol/lun_cc_esxi070 -igroup ccesxi070
51 lun mapping delete -vserver eos-iscsi-1 -path /vol/cc_esxi069_vol/lun_cc_esxi069 -igroup ccesxi069
52 lun mapping create -vserver eos-iscsi-1 -path /vol/cc_esxi069_vol/lun_cc_esxi069 -igroup ccesxi070
53 lun mapping create -vserver eos-iscsi-1 -path /vol/cc_esxi070_vol/lun_cc_esxi070 -igroup ccesxi069

reboot the hosts.

But, now we cannot see the lun at all

Any thoughts ?

cobalt trout
#

The rename would have been easier/non-disruptive.

What is the output of:
set diag (answer y)
Iscsi initiator show -fields tpgroup, initiator, igroup -sort-by vserver, initiator, tpgroup

lean linden
#

I ran your command, but the output doesn't contain the itinitors (iqn numbers), nor the igroups involved for these two hosts, assuming it is what you wanted me to check...

#

the output is long list, so, I didn't post here

cobalt trout
#

sure thing. The "initiator show" command shows all iscsi initiators talking to the netapp. If your hosts are there, then they are not properly configured.

I used that output to help verify multipathing (it is sorted by vserver, then by the initator-iqn, then by tpgroup-the data-lif). I can easily see with my own eyes if everything is setup/connected properly pretty quick, even in a long list

#

so do this...go to each ESXI host and VERIFY the IQN of the two hosts. Then look this:
iscsi initiator show -initiator *iqn*

Where iqn is the IQN from the ESXi hosts (include the * in case there is a typo)

lean linden
#

I used that output to help verify multipathing

"multipathing" is managed on clients, once we are done with configurations on the cluster. I can tell what reporting nodes are, what LIF's being used on the cluster.

But, Is there anyway from the cluster to tell if "multipathing" on the clients has been configured correct, without checking on clients?