What to do after the LUNS are created

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












Our Management bought a New EMC2 VNX storage device, and a guy from the vendor came to create the LUNS.



I honestly have no idea how to configure the EMC SANS as I never got a chance to work on such awesome things. Now finally I got it.



I know that final step is to mount it as a partition.



But what I need to know is what are the things involved between creating the LUNs and mounting the storage as a partition on the server.



I will mount it on Redhat 5.9 and Redhat 6.4










share|improve this question



























    up vote
    2
    down vote

    favorite












    Our Management bought a New EMC2 VNX storage device, and a guy from the vendor came to create the LUNS.



    I honestly have no idea how to configure the EMC SANS as I never got a chance to work on such awesome things. Now finally I got it.



    I know that final step is to mount it as a partition.



    But what I need to know is what are the things involved between creating the LUNs and mounting the storage as a partition on the server.



    I will mount it on Redhat 5.9 and Redhat 6.4










    share|improve this question

























      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      Our Management bought a New EMC2 VNX storage device, and a guy from the vendor came to create the LUNS.



      I honestly have no idea how to configure the EMC SANS as I never got a chance to work on such awesome things. Now finally I got it.



      I know that final step is to mount it as a partition.



      But what I need to know is what are the things involved between creating the LUNs and mounting the storage as a partition on the server.



      I will mount it on Redhat 5.9 and Redhat 6.4










      share|improve this question















      Our Management bought a New EMC2 VNX storage device, and a guy from the vendor came to create the LUNS.



      I honestly have no idea how to configure the EMC SANS as I never got a chance to work on such awesome things. Now finally I got it.



      I know that final step is to mount it as a partition.



      But what I need to know is what are the things involved between creating the LUNs and mounting the storage as a partition on the server.



      I will mount it on Redhat 5.9 and Redhat 6.4







      rhel storage






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Aug 21 at 3:13









      Rui F Ribeiro

      36.7k1271116




      36.7k1271116










      asked Jun 23 '13 at 11:44









      OmiPenguin

      1,470235784




      1,470235784




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          3
          down vote



          accepted










          Usually if you rescan the SCSI bus udev will create the device file for the LUN after which point you treat it like you would any other storage volume (local disk or otherwise). There's a script to do the rescan in the sg3_utils package called rescan-scsi-bus.sh



          Rescanning should be sufficient, but in case it's not (usually indicates a driver issue) rebooting will cause the HBA to log back into the SAN and get a new list of LUNs that have been presented to it.



          You'll be able to see the LUN when you do an ls -l /dev/disk/by-path For example:



          [jadavis6@lrgarfield ~]$ ls -l /dev/disk/by-path
          total 0
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0 -> ../../sda
          lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part1 -> ../../sda1
          lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part2 -> ../../sda2
          lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part3 -> ../../sda3
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:1:0 -> ../../sdb
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:2:0 -> ../../sdc
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0008000000000000 -> ../../sde
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0009000000000000 -> ../../sdf
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0000000000000000 -> ../../sdg
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0008000000000000 -> ../../sdh
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0009000000000000 -> ../../sdi
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0000000000000000 -> ../../sdj
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0008000000000000 -> ../../sdk
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0009000000000000 -> ../../sdl
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0000000000000000 -> ../../sdm
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0008000000000000 -> ../../sdn
          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0009000000000000 -> ../../sdo


          The Fibre Channel LUN's have the -fc- transport listed. -scsi- devices are internal storage.



          Be warned, if the fibre channel card was able to log into the SAN you'll see what's referred to as LUNZ which is apparently one of the ports on the SAN you're connected to. You can tell a path is LUNZ if it's LUN ID (the hex number after the last colon) is all zero's. For example, in the above output this is one of the LUNZ's:



          lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd


          I've never gotten a full explanation from any SAN guy I've talked to as to why Fibre Channel does that, but just know it's going to be there, it's going to be the first LUN the FC sees (so it gets the lowest number), and you can't treat it like a LUN at all, it's just sort of there. Once you start seeing a LUN with a non-zero LUN ID you'll know that's your target LUN.



          EDIT:



          I will say this: LUNZ does make it easier to see if the HBA is able to log into the SAN (although you could still see such by way of FLOGI errors in /var/log/messages). If you install a new HBA and DON'T see a LUNZ off it, that's usually an indication that the firmware on the device or the driver for it needs to be updated.



          EDIT #2:



          These are the steps strictly required, if you're doing pathing, you'll probably want to install PowerPath or configure multipathd. But that's a whole task unto itself. It's better to just mention that, let you do your research and come back with any specific questions.






          share|improve this answer






















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f80416%2fwhat-to-do-after-the-luns-are-created%23new-answer', 'question_page');

            );

            Post as a guest






























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            3
            down vote



            accepted










            Usually if you rescan the SCSI bus udev will create the device file for the LUN after which point you treat it like you would any other storage volume (local disk or otherwise). There's a script to do the rescan in the sg3_utils package called rescan-scsi-bus.sh



            Rescanning should be sufficient, but in case it's not (usually indicates a driver issue) rebooting will cause the HBA to log back into the SAN and get a new list of LUNs that have been presented to it.



            You'll be able to see the LUN when you do an ls -l /dev/disk/by-path For example:



            [jadavis6@lrgarfield ~]$ ls -l /dev/disk/by-path
            total 0
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0 -> ../../sda
            lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part1 -> ../../sda1
            lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part2 -> ../../sda2
            lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part3 -> ../../sda3
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:1:0 -> ../../sdb
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:2:0 -> ../../sdc
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0008000000000000 -> ../../sde
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0009000000000000 -> ../../sdf
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0000000000000000 -> ../../sdg
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0008000000000000 -> ../../sdh
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0009000000000000 -> ../../sdi
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0000000000000000 -> ../../sdj
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0008000000000000 -> ../../sdk
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0009000000000000 -> ../../sdl
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0000000000000000 -> ../../sdm
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0008000000000000 -> ../../sdn
            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0009000000000000 -> ../../sdo


            The Fibre Channel LUN's have the -fc- transport listed. -scsi- devices are internal storage.



            Be warned, if the fibre channel card was able to log into the SAN you'll see what's referred to as LUNZ which is apparently one of the ports on the SAN you're connected to. You can tell a path is LUNZ if it's LUN ID (the hex number after the last colon) is all zero's. For example, in the above output this is one of the LUNZ's:



            lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd


            I've never gotten a full explanation from any SAN guy I've talked to as to why Fibre Channel does that, but just know it's going to be there, it's going to be the first LUN the FC sees (so it gets the lowest number), and you can't treat it like a LUN at all, it's just sort of there. Once you start seeing a LUN with a non-zero LUN ID you'll know that's your target LUN.



            EDIT:



            I will say this: LUNZ does make it easier to see if the HBA is able to log into the SAN (although you could still see such by way of FLOGI errors in /var/log/messages). If you install a new HBA and DON'T see a LUNZ off it, that's usually an indication that the firmware on the device or the driver for it needs to be updated.



            EDIT #2:



            These are the steps strictly required, if you're doing pathing, you'll probably want to install PowerPath or configure multipathd. But that's a whole task unto itself. It's better to just mention that, let you do your research and come back with any specific questions.






            share|improve this answer


























              up vote
              3
              down vote



              accepted










              Usually if you rescan the SCSI bus udev will create the device file for the LUN after which point you treat it like you would any other storage volume (local disk or otherwise). There's a script to do the rescan in the sg3_utils package called rescan-scsi-bus.sh



              Rescanning should be sufficient, but in case it's not (usually indicates a driver issue) rebooting will cause the HBA to log back into the SAN and get a new list of LUNs that have been presented to it.



              You'll be able to see the LUN when you do an ls -l /dev/disk/by-path For example:



              [jadavis6@lrgarfield ~]$ ls -l /dev/disk/by-path
              total 0
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0 -> ../../sda
              lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part1 -> ../../sda1
              lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part2 -> ../../sda2
              lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part3 -> ../../sda3
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:1:0 -> ../../sdb
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:2:0 -> ../../sdc
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0008000000000000 -> ../../sde
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0009000000000000 -> ../../sdf
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0000000000000000 -> ../../sdg
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0008000000000000 -> ../../sdh
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0009000000000000 -> ../../sdi
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0000000000000000 -> ../../sdj
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0008000000000000 -> ../../sdk
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0009000000000000 -> ../../sdl
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0000000000000000 -> ../../sdm
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0008000000000000 -> ../../sdn
              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0009000000000000 -> ../../sdo


              The Fibre Channel LUN's have the -fc- transport listed. -scsi- devices are internal storage.



              Be warned, if the fibre channel card was able to log into the SAN you'll see what's referred to as LUNZ which is apparently one of the ports on the SAN you're connected to. You can tell a path is LUNZ if it's LUN ID (the hex number after the last colon) is all zero's. For example, in the above output this is one of the LUNZ's:



              lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd


              I've never gotten a full explanation from any SAN guy I've talked to as to why Fibre Channel does that, but just know it's going to be there, it's going to be the first LUN the FC sees (so it gets the lowest number), and you can't treat it like a LUN at all, it's just sort of there. Once you start seeing a LUN with a non-zero LUN ID you'll know that's your target LUN.



              EDIT:



              I will say this: LUNZ does make it easier to see if the HBA is able to log into the SAN (although you could still see such by way of FLOGI errors in /var/log/messages). If you install a new HBA and DON'T see a LUNZ off it, that's usually an indication that the firmware on the device or the driver for it needs to be updated.



              EDIT #2:



              These are the steps strictly required, if you're doing pathing, you'll probably want to install PowerPath or configure multipathd. But that's a whole task unto itself. It's better to just mention that, let you do your research and come back with any specific questions.






              share|improve this answer
























                up vote
                3
                down vote



                accepted







                up vote
                3
                down vote



                accepted






                Usually if you rescan the SCSI bus udev will create the device file for the LUN after which point you treat it like you would any other storage volume (local disk or otherwise). There's a script to do the rescan in the sg3_utils package called rescan-scsi-bus.sh



                Rescanning should be sufficient, but in case it's not (usually indicates a driver issue) rebooting will cause the HBA to log back into the SAN and get a new list of LUNs that have been presented to it.



                You'll be able to see the LUN when you do an ls -l /dev/disk/by-path For example:



                [jadavis6@lrgarfield ~]$ ls -l /dev/disk/by-path
                total 0
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0 -> ../../sda
                lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part1 -> ../../sda1
                lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part2 -> ../../sda2
                lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part3 -> ../../sda3
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:1:0 -> ../../sdb
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:2:0 -> ../../sdc
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0008000000000000 -> ../../sde
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0009000000000000 -> ../../sdf
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0000000000000000 -> ../../sdg
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0008000000000000 -> ../../sdh
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0009000000000000 -> ../../sdi
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0000000000000000 -> ../../sdj
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0008000000000000 -> ../../sdk
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0009000000000000 -> ../../sdl
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0000000000000000 -> ../../sdm
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0008000000000000 -> ../../sdn
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0009000000000000 -> ../../sdo


                The Fibre Channel LUN's have the -fc- transport listed. -scsi- devices are internal storage.



                Be warned, if the fibre channel card was able to log into the SAN you'll see what's referred to as LUNZ which is apparently one of the ports on the SAN you're connected to. You can tell a path is LUNZ if it's LUN ID (the hex number after the last colon) is all zero's. For example, in the above output this is one of the LUNZ's:



                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd


                I've never gotten a full explanation from any SAN guy I've talked to as to why Fibre Channel does that, but just know it's going to be there, it's going to be the first LUN the FC sees (so it gets the lowest number), and you can't treat it like a LUN at all, it's just sort of there. Once you start seeing a LUN with a non-zero LUN ID you'll know that's your target LUN.



                EDIT:



                I will say this: LUNZ does make it easier to see if the HBA is able to log into the SAN (although you could still see such by way of FLOGI errors in /var/log/messages). If you install a new HBA and DON'T see a LUNZ off it, that's usually an indication that the firmware on the device or the driver for it needs to be updated.



                EDIT #2:



                These are the steps strictly required, if you're doing pathing, you'll probably want to install PowerPath or configure multipathd. But that's a whole task unto itself. It's better to just mention that, let you do your research and come back with any specific questions.






                share|improve this answer














                Usually if you rescan the SCSI bus udev will create the device file for the LUN after which point you treat it like you would any other storage volume (local disk or otherwise). There's a script to do the rescan in the sg3_utils package called rescan-scsi-bus.sh



                Rescanning should be sufficient, but in case it's not (usually indicates a driver issue) rebooting will cause the HBA to log back into the SAN and get a new list of LUNs that have been presented to it.



                You'll be able to see the LUN when you do an ls -l /dev/disk/by-path For example:



                [jadavis6@lrgarfield ~]$ ls -l /dev/disk/by-path
                total 0
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0 -> ../../sda
                lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part1 -> ../../sda1
                lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part2 -> ../../sda2
                lrwxrwxrwx 1 root root 10 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:0:0-part3 -> ../../sda3
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:1:0 -> ../../sdb
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:01:00.0-scsi-0:2:2:0 -> ../../sdc
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0008000000000000 -> ../../sde
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0009000000000000 -> ../../sdf
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0000000000000000 -> ../../sdg
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0008000000000000 -> ../../sdh
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x5006016d3ee0025f:0x0009000000000000 -> ../../sdi
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0000000000000000 -> ../../sdj
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0008000000000000 -> ../../sdk
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x500601663ee0025f:0x0009000000000000 -> ../../sdl
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0000000000000000 -> ../../sdm
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0008000000000000 -> ../../sdn
                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.1-fc-0x5006016e3ee0025f:0x0009000000000000 -> ../../sdo


                The Fibre Channel LUN's have the -fc- transport listed. -scsi- devices are internal storage.



                Be warned, if the fibre channel card was able to log into the SAN you'll see what's referred to as LUNZ which is apparently one of the ports on the SAN you're connected to. You can tell a path is LUNZ if it's LUN ID (the hex number after the last colon) is all zero's. For example, in the above output this is one of the LUNZ's:



                lrwxrwxrwx 1 root root 9 Jan 27 17:17 pci-0000:1a:00.0-fc-0x500601653ee0025f:0x0000000000000000 -> ../../sdd


                I've never gotten a full explanation from any SAN guy I've talked to as to why Fibre Channel does that, but just know it's going to be there, it's going to be the first LUN the FC sees (so it gets the lowest number), and you can't treat it like a LUN at all, it's just sort of there. Once you start seeing a LUN with a non-zero LUN ID you'll know that's your target LUN.



                EDIT:



                I will say this: LUNZ does make it easier to see if the HBA is able to log into the SAN (although you could still see such by way of FLOGI errors in /var/log/messages). If you install a new HBA and DON'T see a LUNZ off it, that's usually an indication that the firmware on the device or the driver for it needs to be updated.



                EDIT #2:



                These are the steps strictly required, if you're doing pathing, you'll probably want to install PowerPath or configure multipathd. But that's a whole task unto itself. It's better to just mention that, let you do your research and come back with any specific questions.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jun 23 '13 at 12:35

























                answered Jun 23 '13 at 12:27









                Bratchley

                11.7k64386




                11.7k64386



























                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f80416%2fwhat-to-do-after-the-luns-are-created%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    Peggy Mitchell

                    Palaiologos

                    The Forum (Inglewood, California)