<?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: Disk ID's changing how can I ensure volume groups are imported correctly in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437131#M623952</link>
    <description>Thanks although using vgscan I have always felt has an element of risk</description>
    <pubDate>Mon, 06 Dec 2004 07:42:51 GMT</pubDate>
    <dc:creator>Adam Noble</dc:creator>
    <dc:date>2004-12-06T07:42:51Z</dc:date>
    <item>
      <title>Disk ID's changing how can I ensure volume groups are imported correctly</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437128#M623949</link>
      <description>We are making some changes to an external EMC disk array and have witnessed that the disk id's will change once this is complete. We backed out the change as obviously the volume groups failed to import however we need to carry out the work.&lt;BR /&gt;&lt;BR /&gt;I am assuming that I can do a vgexport -s -p -m /tmp/vg02.map -f /tmp/vg02disks /dev/vg02&lt;BR /&gt;&lt;BR /&gt;As far as I am aware this runs in preview mode and will enable me to create a list of disks currently in vg02 aswell as the mapfile. It will not actually export the volumes.&lt;BR /&gt;&lt;BR /&gt;Therefore I assume when the server re-boots I can simply eddit the /tmp/vg02disks file to relate to the new ID's and then do a:-&lt;BR /&gt;&lt;BR /&gt;vgimport -f /tmp/vg02disks /dev/vg02.&lt;BR /&gt;&lt;BR /&gt;Infact do I need a mapfile created??????&lt;BR /&gt;&lt;BR /&gt;Is this the correct way of doing this?</description>
      <pubDate>Mon, 06 Dec 2004 05:41:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437128#M623949</guid>
      <dc:creator>Adam Noble</dc:creator>
      <dc:date>2004-12-06T05:41:26Z</dc:date>
    </item>
    <item>
      <title>Re: Disk ID's changing how can I ensure volume groups are imported correctly</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437129#M623950</link>
      <description>Hi Adam,&lt;BR /&gt;&lt;BR /&gt;Yes. You will have to have the map file otherwise the logical volumes imported will have default names like lvol1, lvol2 etc., Easy way to try is to just specify -s option.&lt;BR /&gt;&lt;BR /&gt;#mkdir /dev/vg02&lt;BR /&gt;#mknod /dev/vg02/group c 64 0x020000&lt;BR /&gt;#vgimport -v -s -m /tmp/vg02.map vg02&lt;BR /&gt;&lt;BR /&gt;If you numerous disks, then the above will take a long time in which case you can modify vg02disks file and import them. Also remove the line that starts with VGID in your vg02.map file before you use it with -f option (call it say vg02.new.map) .&lt;BR /&gt;&lt;BR /&gt;#vgimport -v -m /tmp/vg02.new.map -f /tmp/vg02disks vg02&lt;BR /&gt;&lt;BR /&gt;-Sri</description>
      <pubDate>Mon, 06 Dec 2004 05:50:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437129#M623950</guid>
      <dc:creator>Sridhar Bhaskarla</dc:creator>
      <dc:date>2004-12-06T05:50:19Z</dc:date>
    </item>
    <item>
      <title>Re: Disk ID's changing how can I ensure volume groups are imported correctly</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437130#M623951</link>
      <description>In addition to the solution already detailed, I found a workaround with vgscan.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;I had a similar problem following a firmware upgrade on an EMC array, which left all of the physical paths altered.&lt;BR /&gt;&lt;BR /&gt;I used this process, (it includes a few routines which are probably unnecessary);&lt;BR /&gt;&lt;BR /&gt;vg01 &amp;amp; vg02 were EMC-sourced mounts.&lt;BR /&gt; backed-up all the *.conf and *.mapfiles, i.e.&lt;BR /&gt;vg01.conf backed-up as vg01.conf.bak&lt;BR /&gt;vg01.mapfile   backed-up as vg01.mapfile.bak&lt;BR /&gt;vg02Emcm1.conf backed-up as vg02Emcm1.conf.bak&lt;BR /&gt;vg02Emcm1.mapfile backed-up as &lt;BR /&gt;&lt;BR /&gt;I then performed a vgscan on all device paths, using the â  pâ   (preview) &lt;BR /&gt;# vgscan -a -p -v | tee -a /tmp/before_scan.txt&lt;BR /&gt;&lt;BR /&gt;before_scan.txt;&lt;BR /&gt;&lt;BR /&gt;/dev/vg00           &lt;BR /&gt;/dev/dsk/c0t6d0     &lt;BR /&gt;/dev/dsk/c3t6d0                             &lt;BR /&gt;/dev/vg01           &lt;BR /&gt;/dev/dsk/c5t0d0&lt;BR /&gt;       &lt;BR /&gt;/dev/vg02EMcm1      &lt;BR /&gt;/dev/dsk/c5t0d1     &lt;BR /&gt;/dev/dsk/c5t0d2     &lt;BR /&gt;/dev/dsk/c5t0d3     &lt;BR /&gt;/dev/dsk/c5t0d4     &lt;BR /&gt;                                      &lt;BR /&gt;                    &lt;BR /&gt;/dev/vg03EMcm1      &lt;BR /&gt;/dev/dsk/c5t0d5     &lt;BR /&gt;&lt;BR /&gt;/dev/vg02EMcm1    &lt;BR /&gt;/dev/dsk/c5t0d1   &lt;BR /&gt;/dev/dsk/c5t0d2   &lt;BR /&gt;/dev/dsk/c5t0d3   &lt;BR /&gt;/dev/dsk/c5t0d4   &lt;BR /&gt;                  &lt;BR /&gt;               &lt;BR /&gt;/dev/vg03EMcm1    &lt;BR /&gt;/dev/dsk/c5t0d5   &lt;BR /&gt;/dev/dsk/c5t0d6   &lt;BR /&gt;&lt;BR /&gt;I checked the output against the previous physical mappings of the disks in volume groups vg01, vg02Emcm1 and vg03Emcm1 using the command;&lt;BR /&gt;&lt;BR /&gt;  strings /etc/lvmtab&lt;BR /&gt;&lt;BR /&gt;I then performed the vgscan this time â  for realâ  , using the command;&lt;BR /&gt;&lt;BR /&gt;# vgscan -a -v&lt;BR /&gt;&lt;BR /&gt;Note the â  -pâ   flagâ  s absence, so this command â  shouldâ   actually scan and change the file /etc/lvmtab file.&lt;BR /&gt;&lt;BR /&gt;Well, actually, it didnâ  t. /etc/lvmtab still displayed the old configuration;&lt;BR /&gt;&lt;BR /&gt;So I backed-up the current /etc/lvmtab file&lt;BR /&gt;and then removed it.&lt;BR /&gt;&lt;BR /&gt;Then ran the vgscan again, to re-create the /etc/lvmtab file from new;&lt;BR /&gt;&lt;BR /&gt;# vgscan -a â  v&lt;BR /&gt;&lt;BR /&gt;This worked fine, and the newly-created /etc/lvmtab file now had the correct device file names;&lt;BR /&gt;&lt;BR /&gt;# strings lvmtab&lt;BR /&gt;/dev/vg00                    &lt;BR /&gt;/dev/dsk/c0t6d0              &lt;BR /&gt;/dev/dsk/c3t6d0              &lt;BR /&gt;/dev/vg01                    &lt;BR /&gt;/dev/dsk/c5t0d0              &lt;BR /&gt;/dev/vg02EMcm1               &lt;BR /&gt;/dev/dsk/c5t0d1              &lt;BR /&gt;/dev/dsk/c5t0d2              &lt;BR /&gt;/dev/dsk/c5t0d3              &lt;BR /&gt;/dev/dsk/c5t0d4              &lt;BR /&gt;/dev/vg03EMcm1               &lt;BR /&gt;/dev/dsk/c5t0d5              &lt;BR /&gt;/dev/dsk/c5t0d6 &lt;BR /&gt;&lt;BR /&gt;All that remained was to activate the EMC-hosted volume groups, using the vgchange command;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;# vgchange â  a y /dev/vg01&lt;BR /&gt;&lt;BR /&gt;# vgchange â  a y /dev/vg02Emcm1&lt;BR /&gt;# vgchan</description>
      <pubDate>Mon, 06 Dec 2004 07:37:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437130#M623951</guid>
      <dc:creator>Brendan Newport_2</dc:creator>
      <dc:date>2004-12-06T07:37:00Z</dc:date>
    </item>
    <item>
      <title>Re: Disk ID's changing how can I ensure volume groups are imported correctly</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437131#M623952</link>
      <description>Thanks although using vgscan I have always felt has an element of risk</description>
      <pubDate>Mon, 06 Dec 2004 07:42:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437131#M623952</guid>
      <dc:creator>Adam Noble</dc:creator>
      <dc:date>2004-12-06T07:42:51Z</dc:date>
    </item>
    <item>
      <title>Re: Disk ID's changing how can I ensure volume groups are imported correctly</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437132#M623953</link>
      <description>Adam,&lt;BR /&gt;&lt;BR /&gt;You will not have this problem if you're using VxVM as your volume manager (which HP has recently blessed as the preferred VM for GP-UX..).&lt;BR /&gt;&lt;BR /&gt;But on the case at hand - I have been able to go about this problem by simply doing a vgexport of the VG's with the VGID option (or shared option) so the VGID is part of the output.&lt;BR /&gt;&lt;BR /&gt; /usr/sbin/vgexport -s -p -m /somedir/vgXYZ.map /dev/vgXYZ&lt;BR /&gt;&lt;BR /&gt;Then when you do storage migrations, firmware upgrades, HBA relocations, etc.. etc.. you simply unmount the filesystems, vgchange to inactive and vgexport the VG.&lt;BR /&gt;&lt;BR /&gt;When you boot your system you simply:&lt;BR /&gt;&lt;BR /&gt;/vgimport -m mapfile -s -v vg_name&lt;BR /&gt;&lt;BR /&gt;And to ensure that the disks (or PVs or LUNs..) for a particular VG are all there before you do your vgimport - get the VGID of all the disks in your system and search out.&lt;BR /&gt;&lt;BR /&gt;echo 0x2010?2X|adb /dev/dsk/cXtYdZ|expand|tr -d " "|sed "s/2010://"&lt;BR /&gt;&lt;BR /&gt;HTH.&lt;BR /&gt;</description>
      <pubDate>Mon, 06 Dec 2004 08:48:15 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/disk-id-s-changing-how-can-i-ensure-volume-groups-are-imported/m-p/3437132#M623953</guid>
      <dc:creator>Alzhy</dc:creator>
      <dc:date>2004-12-06T08:48:15Z</dc:date>
    </item>
  </channel>
</rss>

