This email is to be read subject to the disclaimer below.
Hi Jerome,
I admin a medium sized Legato installation run on Widnows 2k3. To prevent
the drives from changing ID's upon reboots you need to enable persistant
binding in your HBA management utility - HBAnyware from Emulex is good if
you use Emulex cards. Basically Windows is handing out any old SCSI ID to
the drives as it detects them. Persistant binding will ensure that you get
the same ID on each device.
I have seen the ame inventory behavior as what you are experiencing, but I
cant for the life of me remember what we did to fix it - if I remember I
will let you know,
Cheers,
Matt
"Landwehr, Jerome" <jlandweh AT HARRIS DOT COM>
Sent by: EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
30/11/2006 12:58 AM
Please respond to
EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please respond
to
"Landwehr, Jerome" <jlandweh AT HARRIS DOT COM>
All email is logged and may be reviewed - Refer policy FP206
To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc
Subject
Re: [Networker] Adding a dedicated storage node in v7.3.2
Firstly - use 'jbedit' rather than jbconfig - you enter most of the info
on the command line, repeating for each device
Yes - deleting a jukebox removes any association of what tapes it was
holding - as one would expect
I'm not personally a NT admin, but from what I remember RSM is the
culprit in the drive mis-ordering - not that it is ever completely fixed
in my experience
HTH
Jerry
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Andy Garman
Sent: Wednesday, November 29, 2006 6:33 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Adding a dedicated storage node in v7.3.2
Hello,
Our v7.3.2 backup server has licences for up to 100 clients, 5
shared
(FC LTO3) drives and 17 dedicated storage nodes. When configuring new
storage nodes, we have been unable to follow the suggested and logical
procedure in the JVM gui as we are requested for storage node licenses
which
we do not have - we have dedicated storage node licenses only. Our
workaround has been to use jbconfig, assigning multiple remote paths for
each physical drive, which causes dedicated storage node licenses to be
allocated automatically.
However, this process involves deleting and recreating the jukebox
every
time a new storage node is needed or an existing jukebox changes its
device
paths. This was inconvenient enough under v7.3, but since the upgrade to
v7.3.2, when the jukebox is recreated, the tape labels are no longer
read in
- we have to reinventory 400 slots each time, taking 3-4 hours).
So I have 3 questions which some helpful people might have useful
suggestions to:
- has anyone got the standard procedure for adding new storage nodes to
work? Or just a better workaround?
- has anyone else observed/solved the same jukebox problem we have seen
of
tapes needing re-inventoried after jukebox recreation? I've checked
obvious
things like barcode scanner enabled and labels to match, but might have
missed something else?
- the two problems above are exacerbated by the tendency for windows
servers
to change their device pathnames on reboot. Do any windows admins have
any
tips for this unix admin to pass on to his windows admin colleagues to
ensure device persistence across system restarts?
Many thanks in advance,
Andy Garman
Computing Services
University of Edinburgh
Scotland UK.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
--------------------
NOTICE - This communication contains information which is confidential and the
copyright of Ernst & Young or a third party.
If you are not the intended recipient of this communication please delete and
destroy all copies and telephone Ernst & Young on 1800 655 717 immediately. If
you are the intended recipient of this communication you should not copy,
disclose or distribute this communication without the authority of Ernst &
Young.
Any views expressed in this Communication are those of the individual sender,
except where the sender specifically states them to be the views of Ernst &
Young.
Except as required at law, Ernst & Young does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained nor that
the communication is free of errors, virus, interception or interference.
Liability limited by a scheme approved under Professional Standards Legislation.
--------------------
If this communication is a "commercial electronic message" (as defined in the
Spam Act 2003) and you do not wish to receive communications such as this,
please forward this communication to unsubscribe AT au.ey DOT com
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|