ADSM-L

Re: [ADSM-L] There has got to be a better way - revisited

2011-02-11 15:59:36
Subject: Re: [ADSM-L] There has got to be a better way - revisited
From: Steven Langdale <steven.langdale AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 11 Feb 2011 20:54:21 +0000
is the WWN for the drive changing?

If so, the servers would/should see a new drive.

On Feb 11, 2011 8:28pm, Zoltan Forray/AC/VCU <zforray AT vcu DOT edu> wrote:
Back a while ago, I posted a similar discussion about the trials and

tribulations of tape drive (TS1120/TS1130) replacement and the work it

caused when the serial number changed (rebooting and reconfiguring all TSM

servers). I was enlightened that the new drives serial number could be

reset to the old drives serial number and the issue of having to reboot

all 7-TSM servers because of a drive replacement, was, I thought,

resolved.



Well, I haven't had a need to drive replacement since then........until

now.



What I discovered was that even with the replacement drive co-opting the

serial number of the failing drive, I still have to reboot all of my

servers.



Yes, I made sure to update the new drives serial number BEFORE plugging in

the fibre cable.



Took the library and drives offline in TSM



Yet, as soon as the failing drive was unplugged (or at least it seems that

way), the /dev/IBMtape? device becomes unavailable and no amount of

stopping/restarting the lin_tape processes will make the drive accessible.

Reboot is required. Any attempt to open the drive via IBMtapeutil fails

(Operation failed with errno 5: Input/output error).



So, what are we doing wrong? How do you handle tape drive

repairs/replacement?



To recap my environment:



IBM3494 with TS1120 and TS1130 drives connected via fibre

CISCO SAN switches

Single path to each drive (not enough switch ports)

RHEL4 and RHEL5 servers

My SAN guy says we are not mapping drives by WWN - pools/groups I think

(sorry - I don't know the terminology) - all tape drives and servers that

use them are separate from disk connections

Zoltan Forray

TSM Software & Hardware Administrator

Virginia Commonwealth University

UCC/Office of Technology Services

zforray AT vcu DOT edu - 804-828-4807

Don't be a phishing victim - VCU and other reputable organizations will

never use email to request that you reply with your password, social

security number or confidential personal information. For more details

visit http://infosecurity.vcu.edu/phishing.html