-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The option in the vm.conf
ENABLE_AUTO_PATH_CORRECTION
will take care of what you need between reboots as it has reconfigured
without issue for me with a 2.6 AMD64 kernel for more that 2 years.
So if all underlying drivers and SANs have been configured correctly, then
a /dev/nst# set of character devices have been created. Once you configure
them in the gui or tpconfig, NBU will perform a scsi query and attach the
outputed serial number to that tape devices. With the above configuration
option, it will adjust the tape name to the new /dev/nst# on reboot if there
was a change.
If you want to go down the route of udev, the default configuration will
point to /dev/tape%e but the NBU tape drive configuration tools I don't think
will recognize anything but the no rewind devices (/dev/nst?) format although
I've never tried.
It looks like you may be on a RH4 based on your kernel version. FYI, the udev
and multipathd implementation in RH5 was cleaned up quite a bit from and admin's
management perspective.
Thanks
Peter
Peter DrakeUnderkoffler
Xinupro, LLC
617-834-2352
Jonathan Dyck wrote:
> For some reason I don't think this post made it through... Here's
> attempt number 2:
>
>
> -----Original Message-----
> *From:* Jonathan Dyck
> *Sent:* January 08, 2009 3:38 PM
> *To:* veritas-bu AT mailman.eng.auburn DOT edu
> *Subject:* Question Regarding Linux 2.6 kernel udev rules for tape
> devices
>
> Hello all,
> I'm building a new NBU 6.5 environment on RedHat...
>
> [root@<>dev]# uname -a
> Linux <>2 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64
> x86_64 x86_64 GNU/Linux
> and am trying to wrap my head around the FC-SCSI tape device
> configuration. I have seen/heard mention that udev rules should be
> create to ensure that persistent naming occurs in the event that the
> server gets rebooted, SAN changes are made, new devices are added, etc
>
> The way I understand things, the following is the method to get
> things working on the server side:
> 1) Kernel detects tape scsi devices and creates /dev/nst## device
> files (and /dev/st## device files)
> ie: /dev/nst1
>
> 2) Links are created via the default udevrules , create "tape"
> device symlinks.
> ie: tape81 -> nst23a
>
> 3) Run "/dev/MAKEDEV sg" to create the sg links that Netbackup needs
> to populate the device database
> Question here: does the MAKEDEV command look for /dev/nst
> devices? Or is it based on the "tape#" symlinks described above?
>
> If the answer is that is uses the symlinks, then I think I
> understand how the udev rules would be used (scsi_id -g -u -s <nst
> device> used to get the scsi inquiry string, create a rules so that
> the result of that inquiry always creates the same tape#). If not,
> could someone enlighten me?
>
> Cheers,
> Jon
>
>
>
>
>
>
>
>
> ====================================================================================
>
> La version française suit le texte anglais.
>
> ------------------------------------------------------------------------------------
>
> This email may contain privileged and/or confidential information, and the
> Bank of
> Canada does not waive any related rights. Any distribution, use, or copying
> of this
> email or the information it contains by other than the intended recipient is
> unauthorized. If you received this email in error please delete it
> immediately from
> your system and notify the sender promptly by email that you have done so.
>
> ------------------------------------------------------------------------------------
>
> Le présent courriel peut contenir de l'information privilégiée ou
> confidentielle.
> La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
> diffusion,
> utilisation ou copie de ce courriel ou des renseignements qu'il contient par
> une
> personne autre que le ou les destinataires désignés est interdite. Si vous
> recevez
> ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
> délai à
> l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
> votre
> ordinateur toute copie du courriel reçu.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org
iD8DBQFJa3dMl+lekZRM55oRAmf9AJ4y9ANwW8UPesj/3oFC+KaxivPYrgCgrPXK
640XHT01JbKqAKgOBkX1fsA=
=GK2t
-----END PGP SIGNATURE-----
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
