<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: EVA Lun problem in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957981#M27344</link>
    <description>Marco, here is a snippet from the SecurePath manual for Linux that addresses your issue...&lt;BR /&gt;&lt;BR /&gt;""The Linux operating system does not provide built-in LUN persistence. Lack of&lt;BR /&gt;LUN persistence means that if you add or delete physical LUNs or disks and&lt;BR /&gt;reboot your system, there is a probability that the device mnemonics will change&lt;BR /&gt;in an undesirable way.""&lt;BR /&gt;&lt;BR /&gt;The SecurePath software can be installed on your system to address device persistance with the sps program, however if you don't have SP installed, there are ways of identifying your LUNS when adding and removing EVA devices from your linux system.  Is that what you are looking for, a means of identification?&lt;BR /&gt;</description>
    <pubDate>Thu, 08 Mar 2007 21:16:31 GMT</pubDate>
    <dc:creator>CelesteG</dc:creator>
    <dc:date>2007-03-08T21:16:31Z</dc:date>
    <item>
      <title>EVA Lun problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957978#M27341</link>
      <description>Hi all,&lt;BR /&gt;i've a problem with a Redhat AS 3.2&lt;BR /&gt;I configured two luns on an EVA3000.&lt;BR /&gt;My problem is that if the server reboot, sometimes it change the special files associated to LUN.&lt;BR /&gt;The /dev/sda become /dev/sdb and this is a huge problem.&lt;BR /&gt;&lt;BR /&gt;Any suggestion please?&lt;BR /&gt;Thanks</description>
      <pubDate>Thu, 08 Mar 2007 06:08:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957978#M27341</guid>
      <dc:creator>Marco_113</dc:creator>
      <dc:date>2007-03-08T06:08:41Z</dc:date>
    </item>
    <item>
      <title>Re: EVA Lun problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957979#M27342</link>
      <description>what kind of fiber card do you have?</description>
      <pubDate>Thu, 08 Mar 2007 08:22:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957979#M27342</guid>
      <dc:creator>Court Campbell</dc:creator>
      <dc:date>2007-03-08T08:22:32Z</dc:date>
    </item>
    <item>
      <title>Re: EVA Lun problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957980#M27343</link>
      <description>The devlabel software attempts to address the device naming issue in a different manner than file system labels. The devlabel software is run by Red Hat Enterprise Linux whenever the system reboots (and whenever hotpluggable devices are inserted or removed).&lt;BR /&gt;&lt;BR /&gt;When devlabel runs, it reads its configuration file (/etc/sysconfig/devlabel) to obtain the list of devices for which it is responsible. For each device on the list, there is a symbolic link (chosen by the system administrator) and the device's UUID (Universal Unique IDentifier).&lt;BR /&gt;&lt;BR /&gt;The devlabel command makes sure the symbolic link always refers to the originally-specified device â   even if that device's name has changed. In this way, a system administrator can configure a system to refer to /dev/projdisk instead of /dev/sda12, for example.&lt;BR /&gt;&lt;BR /&gt;Because the UUID is obtained directly from the device, devlabel must only search the system for the matching UUID and update the symbolic link appropriately.&lt;BR /&gt;&lt;BR /&gt;# devlabel add -s /dev/my_stable_disk_name -d /dev/sda</description>
      <pubDate>Thu, 08 Mar 2007 08:22:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957980#M27343</guid>
      <dc:creator>Ivan Ferreira</dc:creator>
      <dc:date>2007-03-08T08:22:41Z</dc:date>
    </item>
    <item>
      <title>Re: EVA Lun problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957981#M27344</link>
      <description>Marco, here is a snippet from the SecurePath manual for Linux that addresses your issue...&lt;BR /&gt;&lt;BR /&gt;""The Linux operating system does not provide built-in LUN persistence. Lack of&lt;BR /&gt;LUN persistence means that if you add or delete physical LUNs or disks and&lt;BR /&gt;reboot your system, there is a probability that the device mnemonics will change&lt;BR /&gt;in an undesirable way.""&lt;BR /&gt;&lt;BR /&gt;The SecurePath software can be installed on your system to address device persistance with the sps program, however if you don't have SP installed, there are ways of identifying your LUNS when adding and removing EVA devices from your linux system.  Is that what you are looking for, a means of identification?&lt;BR /&gt;</description>
      <pubDate>Thu, 08 Mar 2007 21:16:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957981#M27344</guid>
      <dc:creator>CelesteG</dc:creator>
      <dc:date>2007-03-08T21:16:31Z</dc:date>
    </item>
    <item>
      <title>Re: EVA Lun problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957982#M27345</link>
      <description>Thanks for reply.&lt;BR /&gt;Yes Celeste, is exactly what i need.&lt;BR /&gt;I think i have to edit /etc/CPQswsp/sppf file?&lt;BR /&gt;Thanks</description>
      <pubDate>Fri, 09 Mar 2007 03:42:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957982#M27345</guid>
      <dc:creator>Marco_113</dc:creator>
      <dc:date>2007-03-09T03:42:26Z</dc:date>
    </item>
    <item>
      <title>Re: EVA Lun problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957983#M27346</link>
      <description>Editing the sppc Secure Path file it works great.&lt;BR /&gt;Thanks.&lt;BR /&gt;Now I' ve another problem.&lt;BR /&gt;When system boots, it don't see the lun until i do hp_rescan -a command.&lt;BR /&gt;&lt;BR /&gt;Sometimes i solved this problem:&lt;BR /&gt;1)put in /etc/modules.conf  options scsi_mod max_luns=127&lt;BR /&gt;&lt;BR /&gt;2)rebuilding image with mkinitrd -v&lt;BR /&gt;&lt;BR /&gt;But this time it still doesn't work...&lt;BR /&gt;Any suggestion??&lt;BR /&gt;Thanks</description>
      <pubDate>Fri, 09 Mar 2007 05:07:21 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957983#M27346</guid>
      <dc:creator>Marco_113</dc:creator>
      <dc:date>2007-03-09T05:07:21Z</dc:date>
    </item>
    <item>
      <title>Re: EVA Lun problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957984#M27347</link>
      <description>Marco,&lt;BR /&gt;I didn't make any changes to my modules.conf file.  &lt;BR /&gt;&lt;BR /&gt;Question:  Does your secure path not work.  if you have SP installed then you can do a 'spmgr display' and that will show you all the luns that you have presented to the server from the EVA.&lt;BR /&gt;&lt;BR /&gt;The sppf file is the persistence file for the sps program.  I use it on other systems for mappings but I don't trust it as much because I have seen duplicate LUN entries in that file that I think have caused us problems in the past.  I'm glad it worked for you.  &lt;BR /&gt;&lt;BR /&gt;To address your last inquiry - and then some:&lt;BR /&gt;(NOTE: This is LUN EVA mgmt with NO SecurePath involved.  Just the Linux OS and the fibre utilities.)&lt;BR /&gt;When a LUN is added, you have to do a pvcreate on that LUN before it will be acknowledged by the system as a physical device to be utilized. SP does this but remember we are not utilizing SP on this system).  &lt;BR /&gt;So, to identify which LUN to perform the pvcreate on do a df to get the logical volume info.&lt;BR /&gt;Then do a pvscan to tie that logical volume to a physical device on your system.  We use spvXX for all our EVA LUN assignments (/dev/spv01, /dev/spv02, etc..)&lt;BR /&gt;&lt;BR /&gt;df --&amp;gt;gives me--&amp;gt;  /dev/spv01/lvol1 &lt;BR /&gt;pvscan --&amp;gt;gives me--&amp;gt; pvscan -- ACTIVE   PV "/dev/sdh" of VG "spv01" &lt;BR /&gt;&lt;BR /&gt;So I see that /dev/spv01 is created on the sdh device.  Do this for all your logical volumes and you'll have the correct mappings for your currently utilized physical devices.  Now execute &lt;BR /&gt;/opt/hp/hp_fibreutils/hp_rescan to resan your LUNS (if you have just performed a reboot you shouldn't have to do this.)&lt;BR /&gt;and&lt;BR /&gt;/opt/hp/hp_fibreutils/lssd&lt;BR /&gt;&lt;BR /&gt;The devices you see listed from the lssd command that were not in the list when you verified your current physical devices are the devices that you need to perform a pvcreate on.  Once you do a pvcreate on the device you can do a pvscan and you will see the newly added device and their sizes.&lt;BR /&gt;&lt;BR /&gt;You can now perform LVM configurations on these devices they will not disappear or move unless they are removed from the system for additional LUN configuration. &lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 09 Mar 2007 21:11:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/eva-lun-problem/m-p/3957984#M27347</guid>
      <dc:creator>CelesteG</dc:creator>
      <dc:date>2007-03-09T21:11:09Z</dc:date>
    </item>
  </channel>
</rss>

