Tivoli Storage Manager Server 5.5.3

I spent yesterday afternoon upgrading our TS7530, and in my fad I also upgraded TSM to 5.5.3. Now, once I started TSM it quickly started complaining about the paths to the drives.

I thought maybe this is a mere device problem (we have had them before), so I rebooted the boxes. But still no luck and I went home after about an hour of trying without any luck. In the morning, my co-worker called our trustworthy IBM service partner, and the TSM consultant said he had the exact, same problem yesterday. We would have two options:

  1. Enable the option SANDISCOVERY, with the (completely undocumented) Passive setting (setopt SANDISCOVERY PASSIVE)
  2. Downgrade back to 5.5.2

For now, we implemented the first option, in the hope that’ll solve our troubles. And it actually does.

Mass-updating Tivoli Storage Manager drive status

I was fighting with our VTL again, and TSM was thinking all the drives were offline. In order to update the drive status, you’d need to go into the ISC and select each drive and set them to ONLINE. Since I’m a bit click-lazy, I wrote a simple nested for-loop, which gives me the output to update all the drives at once:

Result is a list like this:

The same goes for mass-updating the path status:

Result is a list like this:

TS7530 authentification failure

Today, I had a rather troublesome morning. Once I got to work, Nagios was already complaining about the lin_taped on one of our TSM servers, which apparently failed due to too many SCSI resets. Additionally, I can’t login using the VE console (I can login however using SSH) so I ended up opening up a IBM Electronic Service Call (ESC+).

Using SSH, I can get some information on the VE’s status:

After looking a bit deeper, it seems that none of the two TSM server is able to see the IBMchanger devices for the first VTL. The second is perfectly visible, just not the first. After putting both VE nodes into suspended failover, gathering support data for the IBM support from both VE’s and the Brocade SAN switches, apparently everything works again. I guess the library does have “self healing” properties.

IBM TS7530 and the Virtualization Engine for Tape Console

I just had yet another support call with IBM, concerning the Tape Console (or VE console, courtesy of Falconstor). My basic problem was/is, that I, as a german person, do have a german Windows Server 2003 installation. Now, if you do have german decimal number format selected in the regional settings, the display is gonna be kinda impaired and you’re gonna see something like this:

VE console with german decimal number format

And now compared to the english decimal number format:

VE console with english decimal number format

This time, the IBM support was quite fast in answering to my ESC, more or less to my satisfaction. Basic statement from IBM is: The VTL console isn’t supported on any german Windows OS. It’s only supported on a english Windows OS.

Sidenote: Amount of Slots per Virtual Tape Library

Well, I just stumbled about this again (and I don’t know right now whether or not this is documented inside a RedBook or not) today, so I thought maybe I’m gonna write it down.

Slot-Amount Property of a Virtual Tape Library
Slot-Amount Property of a Virtual Tape Library

Please keep in mind, when creating the virtual library to think hard about the amount of slots you might need. It ain’t that bad, you just can’t decrease the amount anymore.  So if you think about creating 50 different virtual tape libraries with 500 slots each on your TS7530, think again. The current software level only supports 25.000 slots on a global level.

Working with IBM’s Virtualization Engine Console

Recently, we got the recommendation from our system partner to use static allocated tape cartridges instead of dynamic allocated ones. Apparently using dynamic allocating cartridges comes with a performance penalty if more than a few nodes are backing up a large amount of data at once.

And yet again, I noticed that the IBM Virtualization Engine Console (aka Falconstor Software) is really error prone.

In order to change the allocation type, we had to shred the old cartridges first (500 x ~100M up till now), chance the allocation type at the virtual tape library level, and then recreate the 500 cartridges with a fixed size (500x 102400MB). Now, as I was kinda optimistic, I decided to create all 500 cartridges at once.

Failure during the initiation of 500 virtual catridges

So I ended up creating the 500 cartridges in steps of 45. Which isn’t that big of a deal. But, as we do have two separate logical virtual tape libraries (basically the whole TS7530 is partitioned into two tape libraries), we had to do it for the second one too. But I told myself “Come on, try the maximum amount again!” … And guess what:

Successful initiation of 510 virtual catridges

That worked ❓ Please, don’t ask me why the hell it’s working for one virtual tape library on the same system (well, different virtualization engine), but ain’t for the other one … 😯

Distribution running on IBM TS7530 Virtualization Engine

Well, I was just a bit curious earlier what distribution might be running on our IBM TS7530 Virtualization engines .. well, I just had a look-see ..

Main difference to a “normal” SUSE Linux Enterprise Server 10 installation (there’s about zip normal with that kind of installation, thus the quotes) thus far are:

  1. the build for the VE uses busybox as init
  2. IBM stripped man/info
  3. they are running Xorg/Fluxbox on it

Just don’t ask me why there’s a DE (desktop environment) running, it ain’t even hooked up to a monitor. Only reason would be for the RSA’ remote monitor stuff … *lala*

Read More

IBM TS7530 and DNS

Well, we had our TS7530 delivered in late September, the day after the IBM service guys came by to prep the VTL for our needs (IBM sells the thing as black box). Now, since that day; they fought with the Call Home functionality. The trouble was simply, that the Call Home Service running on the Virtualization Engines just didn’t start.

After about 6 weeks of trial and error (and the IBM service guys popping in every second week), they finally found the cause of the Call Home Service not being able to start. Domain Name Resolution. Neither the IP addresses of the VE’s nor the VE console were registered in our DNS/or local host files.

After I walked over to the networking department and had them register them IP addresses, everything is honky donkey.

IBM TS7530 engine failover and HBA mode

Well, when they delivered the VTL about four weeks ago, nobody figured this thing would be such a mess. Apparently IBM hasn’t set up that much VTL’s with engine failover.

Point being, the VE’s have eight HBA ports (four inside, four outside the black box). Now, as they configured the VTL, the ports were all in initiator mode. And we needed the fourth port in target mode as well, as it’s better to have 4 independent paths to the VTL. The only problem was, the VE console didn’t think so.

There is no way in hell you can switch the darn HBA port to the target mode. — Well, IBM just called and told us the solution.

Disolve the Failover group, reconfigure the HBA port and then recreate the Failover group. Tada …..

IBM TS7530 zoning

At first, as we prepped the zoning for the VTL, we did it WWN-based. Now the trouble with the HBA’s of the VTL is simply that it has different WWPN’s on the same WWN. And WWN-based zoning simply doesn’t allow access to that.

So off we went and switched to Switchport-based zoning, and see. It just works *shrug*