So in your migration, I'd zone the existing disks to your RHEL 5/6 server then use the rescan-scsi-bus.sh script to map in the disks through the HBA and from there you can duplicate your setup and map the disks to a filesystem.<div>
<br></div><div>But, beware that these are probably not on a clustered filesystem (gfs ,etc), so unmount it from the Suse side first before mounting on the RHEL side. You don't want the systems both messing with data on the same time on a ext3 or ext4 filesystem.<br>
<br><div class="gmail_quote">On Sat, Apr 16, 2011 at 11:23 AM, Andrew Wade <span dir="ltr"><<a href="mailto:andrewiwade@gmail.com">andrewiwade@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I work on Fiber Channel connected SAN disks on RHEL 4, and 5.<div><br></div><div>First you need to enable multipath</div><div><br></div><div>service multipathd start</div><div>chkconfig multipath on</div><div><br></div><div>
Next, you need to install (for RHEL 5) sg3 ultils. Make sure you're on the right Channel in Red Hat Satellite to get those packages.</div><div><br></div><div>yum install sg3*</div><div><br></div><div>Next, zone the LUNS to your WWN of your HBAs on your desired servers.</div>
<div><br></div><div>Then to discover the Luns that were zoned to your sever, look in /usr/bin/rescan-scsi-bus.sh</div><div><br></div><div><br></div><div><br></div><div>If you have RHEL 4, I'd install the qlogic san surfer utils to use their script to scan in the luns. In RHEL 5, native sg3 utils work great and you don't have to worry about patching your initrd, etc.</div>
<div><br></div><div><br></div><div>Andrew Wade</div><div>RHCE</div><div>This script with no options scans the hba's for new luns and maps them in.</div><div><br></div><div>Before running the script, you should make a backup copy of /var/lib/multipath/bindings</div>
<div><br></div><div>Then run the rescan-scsi-bus.sh script.</div><div><br></div><div>Next do a diff on /var/lib/multipath/bindings and your /var/lib/multipath/bindings.bk</div><div><br></div><div>You'll see the new LUN that got added.</div>
<div><br></div><div>multipath -ll will confirm all the luns you've added</div><div><br></div><div>Now, for custom aliases, you go back to your bindings file and delete the entry it made called mpath0 and the uid of the disk.</div>
<div><br></div><div>Then edit your multipath.conf to use the uid of the disk (which you see in multipath -ll ) and give it the alias you want ie: oracle_asm01 , etc.</div><div><br></div><div>Then you run multpath -v3 to reread your multipath.conf and rebuild the mulitpath configuraton with your new disk alias (instead of the generic mpath0, mpath1, etc.)</div>
<div><br></div><div>Next, look at /etc/multipath.conf (or /etc/multipath/multipath.conf I'd have to look). Here you can define your aliases if you have any.<div><div></div><div class="h5"><br><br><div class="gmail_quote">
On Fri, Apr 15, 2011 at 7:50 PM, Greg Freemyer <span dir="ltr"><<a href="mailto:greg.freemyer@gmail.com" target="_blank">greg.freemyer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For figuring out what you have:<br>
<br>
You're getting too complex for what seems a simple job.<br>
<br>
FC volumes are scsi normally, so /dev/sdb, etc is likely the drives.<br>
<br>
Just like a physical drive, a FC volume can be used in whole or partitioned.<br>
<br>
To get the full unpartitioned volume size, look in /sys/block/sdb/...<br>
(You can also just call df.)<br>
<br>
You should be able to get partition info from /proc/partitions<br>
<br>
You should see all of your mount points the traditional way. ie. Look<br>
in /etc/fstab and/or run mount.<br>
<br>
The key thing is FC drives fit into the normal scheme at the level you<br>
are talking about.<br>
<br>
You will have a little more fun setting up the new environment and<br>
mounting the volumes.<br>
<br>
Also, you can't tell how the raid setup is done from the basic linux<br>
side. (There may be management software that tells you, but that will<br>
be a separate thing. Likely the storage guys have that info and you<br>
don't. Trouble is they need to know more detail than just /dev/sdb<br>
nomenclature to know which volume you are talking about on their end.)<br>
<br>
Greg<br>
<div><div></div><div><br>
<br>
<br>
<br>
On Fri, Apr 15, 2011 at 4:51 PM, Damon L. Chesser <<a href="mailto:damon@damtek.com" target="_blank">damon@damtek.com</a>> wrote:<br>
> I have a bunch of Suse 9.3 servers with various apps that need to be<br>
> migrated to RHEL 5 or 6.<br>
><br>
> I have back end SANs attached via QLogic hbas.<br>
><br>
> How do I verify how the attached storage is mounted (ie, this mount is<br>
> remote via the hba).<br>
><br>
> There is no /etc/mulitpath.conf<br>
><br>
> What I am looking for is a way I can get info and make a "map" that I<br>
> can duplicate on the new OS. The new storage will be entirely new<br>
> partitions/luns on completely different LUNs, but the "structure" might<br>
> need to be the same, ie: /somemount is 17G /somemount2 is 15G etc.<br>
><br>
> /dev/disk/by-* has by-id and by-uuid and by-path.<br>
><br>
> I know this is both rather simple and broad, but I have zero fiber/HBA<br>
> experience and it would appear I don't know the proper search terms to<br>
> google.<br>
><br>
> If it matters the back end is (old) is a Hitachi and I don't know the<br>
> front end. I will not be tasked with slicing up the LUNs, but reporting<br>
> what sizes I need them to be, then mounting the partitions with the<br>
> proper mount points on the new OS.<br>
> --<br>
> Damon<br>
> <a href="mailto:damon@damtek.com" target="_blank">damon@damtek.com</a><br>
><br>
> _______________________________________________<br>
> Ale mailing list<br>
> <a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
> <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
> <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
Greg Freemyer<br>
Head of EDD Tape Extraction and Processing team<br>
Litigation Triage Solutions Specialist<br>
<a href="http://www.linkedin.com/in/gregfreemyer" target="_blank">http://www.linkedin.com/in/gregfreemyer</a><br>
CNN/TruTV Aired Forensic Imaging Demo -<br>
<a href="http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/" target="_blank">http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/</a><br>
<br>
The Norcross Group<br>
The Intersection of Evidence & Technology<br>
<a href="http://www.norcrossgroup.com" target="_blank">http://www.norcrossgroup.com</a><br>
<div><div></div><div><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>