Sanlun netapp utility usage examples

-

Here are some example of using sanlun command to check information about LUNs from netapp, mapped on to your host.

# sanlun fcp show adapter -c

Displays the following output:

Enter the following command on controllers (running in 7-mode only)to create an initiator group for this system:

              igroup create -f -t linux "hostname" 1abcdef0123456ff 1abcdef0123456fe


# sanlun fcp show adapter host0

Displays the following output:

host0              WWPN:1abcdef0123456ff


# sanlun lun show -d /dev/sdb

Displays the following output:

controller(7mode)/                                            device          host                  lun

vserver(Cmode)       lun-pathname                             filename        adapter    protocol   size    mode

----------------------------------------------------------------------------------------------------------------

       vs0                  /vol/volname/lun2                        /dev/sdb        host0      FCP        1g      C


# sanlun lun show -v -d /dev/sdcx

Displays the following output:


vserver              lun-pathname              filename        adapter    protocol   size    mode

-------------------------------------------------------------------------------------------------

vs0                  /vol/auto_vol196_4/lun1_1 /dev/sdcx       host29     iSCSI      3g      C


LUN Serial number: 2Fgnl+9slW1d

Controller Model Name: FAS3170

Vserver iSCSI IP address: 192.168.10.99

Vserver iSCSI port number: 3260

Vserver IP address: 192.168.200.78

Vserver volume name: auto_vol196_4   MSID::0x00000000000000000000000080000413

Vserver snapshot name:


# sanlun lun show -wwpn 200400a0981047ca

Displays all the devices reachable through the controller port with WWPN 200400a0981047ca:

controller(7mode)/   target                                                      device          host       lun

vserver(Cmode)       wwpn               lun-pathname                             filename        adapter    size    mode

------------------------------------------------------------------------------------------------------------------------

vs0                  200400a0981047ca   /vol/volname/lun2                        /dev/sdr        host10     1g      C

vs0                  200400a0981047ca   /vol/volname/lun1                        /dev/sdq        host10     1g      C

vs0                  200400a0981047ca   /vol/volname/lun2                        /dev/sdj        host9      1g      C

vs0                  200400a0981047ca   /vol/volname/lun1                        /dev/sdi        host9      1g      C


The output will be the same for the command "sanlun lun show -wwpn 20:04:00:a0:98:10:47:ca".


# sanlun lun show -pv vs0:/vol/volname/lun2

Displays the information for the LUN "/vol/volname/lun2" on the vserver "vs0" in case of native multipathing (DM-Multipath):


ONTAP Path: vs0:/vol/volname/lun2

 LUN: 1

 LUN Size: 1g

Host Device: 360a980003246664c422b397a54625875

Mode: C

Multipath Policy: round-robin 0

DM-MP Features: 1 queue_if_no_path

Hardware Handler: 1 alua

Multipath Provider: Native

----------- --------- ---------- ------- ------------ ---------------------------------------------- ----------

host      vserver            host:

dm-mp       path      path       /dev/   chan:        vserver                                        major:

state       state     type       node    id:lun       LIF                                            minor

----------- --------- ---------- ------- ------------ ---------------------------------------------- ----------

active      up        primary    sdd     9:0:0:1      fcp_lif1                                       8:48

active      up        primary    sdp     10:0:2:1     fcp_lif2                                       8:240

active      up        secondary  sdf     9:0:1:1      fcp_lif3                                       8:80

active      up        secondary  sdr     10:0:3:1     fcp_lif4                                       65:16

Comments

Post a Comment

Popular posts from this blog

VLAN External Network in Openshift using NMState Operators and Multus

-
Image
NMstate operators and Multus CNI provide us with plugins and APIs, to set up external network in openshift container ecosystem. Let us see how we can implement a external VLAN networking for certain pods/VMs apart from, pods/VMs using internal cluster networking. When we install NMState operator, it avails us 3 different APIs, namely: Node Network Configuration Policy : Node level network settings implementation.          # oc get nncp Node Network State : The current state of node network is stored in this.         # oc get nns/<node-name> Node Network Configuration Enactment : The status of NNCP implementation across cluster nodes, is checked in this object.         # oc get nnce Network Attachment Definition (NAD) : Apart from above APIs, we will also make use of NAD from multus CNI plugin framework. This implements namespaced object that exposes existing layer 2 network dev...
Read more

Migrating from OpenshiftSDN to OVNKubernetes CNI

-
APIs involved in this migrations are: Network.operator.openshift.io Network.config.openshift.io Operators involved in this migrations are: Cluster Network Operator (CNO) Machine Config Operator (MCO) Refer to pre-requisite steps here , jotted in another post. Update to latest compatible z-stream .  With  that taken care, proceed below. 1> Backup existing cluster network config:      # oc get Network.config.openshift.io cluster -o yaml > cluster-openshiftSDN.yaml 2> Verify that  OVN_SDN_MIGRATION_TIMEOUT   environment variable is set and is  equal to  0s. 3> Set the migration value to null in CNO object cluster:                  # oc patch Network.operator.openshift.io cluster  -- type='merge'  --patch '{"spec":{"migration":null}}' At this time, CNO updates status of Network.config.openshift.io   CR  named  cluster accordingly. MCO rolls out an update to sys...
Read more

Updating Z-stream of version in Openshift Container Platform

-
Whenever we want to upgrade the OCP to next recommended upgrade path, we want to first move to latest patch version of major and minor version of OCP we are running. For instance, if your Openshift is version 4.15.11 (x.y.z) then, Major (x) version is 4, Minor (y) version is 15 and patch (z) version is 11. First update the master/control node and then worker nodes. The worker nodes in case of update can differ from control node by y-2. This allows to plan for update in large clusters that is staggered across in time. With that bit cleared let us see the procedure to update the z version of OCP version. 1> Just run following to lists the compatible update releases # oc adm upgrade Or run below to see available updates, # oc adm upgrade --include-not-recommended Note: Always consult the OSUS upgrade Graph for valid path upgrades 2> After having made the decision, considering impact of updates on existing set-up, go ahead and update the control node. # oc adm upgrade --to=4.15.3...
Read more