For anyone who liked the Table Of Contents feature, I have had to temporarily remove it because the javascript was not playing nice with IE or Firefox (at least not on my system). The only browser that handled it correctly was Google Chrome. I hope to have it back soon, I liked the feature.
Tuesday, September 23, 2008
Wednesday, September 17, 2008
The BACKUP VM command is not supported on this client (ANS1184W)
Just a heads up, so others don't run into this - TSM Integration w/VCB is not supported on x64.
As per this posting to ADSM-L by Andy many months ago:
At the time 5.5 VCB support was being developed, the 64-bit VMware VCB framework was not available (though I think one has since been introduced). So TSM support is currently 32-bit Windows 2003.
Good news is that 'backup vm' works on the x64 platform when using the x32 client.
x64 binaries - v5.5.1.0 - C:\progra~1\tivoli\tsm\baclient
x32 binaries - v5.5.1.0 - C:\progra~1\tivoli\tsm\baclient32C:\progra~1\tivoli\tsm\baclient32.dsmc.exe backup vm -vmlist="fileserver[fileserver_fs]"
Posted by Geoffrey Huntley at 9/17/2008 0 comments Links to this post
Storage Agent Device Issue
So one of my co-workers was tasked with figuring out why a drive was shown in TSM as being assigned to a storage agent when the storage agent was not actually using it (we had even restarted the agent and the library controller still showed the agent as owner of the drive). As it turns out there is an issue with down level TSM device drivers being used between an AIX TSM server and Windows Storage agents. You can find the APAR here. Here is a brief rundown of the problem.
After a review with the Windows and AIX Device Driver development team, it was determined that one of the Windows STA's placed a persistent registration on a drive, failed the persistent reservation, and then failed to release the registration during the recovery path. The registration causes a problem for AIX but not Windows due to the differences in SCSI 2 and SCSI 3 used by Windows and AIX. This hasbeen fixed and the recommendation was to upgrade to the current Windows Device Driver - 6.1.9.3. If you are not at 6.1.9.3 or higher, this is most likely your causing your problem.You can download the latest driver from here:Here is the tsm apar I mentioned:
Posted by Chad_Small at 9/17/2008 0 comments Links to this post
Monday, September 01, 2008
Defaults should never be trusted
I've performed a few audits recently and this one keeps popping up, again and again!
Please be aware that the defaults provided when defining a new storage pool will turn on collocation by GROUP. If this default is specified and no collocation groups are defined then the TSM server will collocate data by NODE!
Pleasant little surprise eh?
COLlocate
Specifies whether the server attempts to keep data belonging to a single client node, group of client nodes, or client file space stored on as few volumes as possible. This parameter is optional. The default value is GROUP.
If you specify COLLOCATE=GROUP but do not define any collocation groups or if you specify COLLOCATE=GROUP but do not add nodes to a collocation group, data is collocated by node.
It never hurts to double check everything, here's some queries I use all the time to sanity check collocation: (replace the stgpool_name as needed)
- select stgpool_name, access, collocate, maxscratch, reusedelay from stgpools
- select count(distinct node_name) as "Number of Nodes", volume_name from volumeusage where stgpool_name='%_TAPE' group by volume_name order by "Number of Nodes" desc
- select count(distinct volume_name) as "Number of Tapes", node_name from volumeusage where stgpool_name='%_TAPE' group by node_name, stgpool_name order by "Number of Tapes" desc
- select count(distinct volume_name) as "Number of Tapes", node_name, stgpool_name from volumeusage group by node_name, stgpool_name order by "Number of Tapes" desc
Posted by Geoffrey Huntley at 9/01/2008 1 comments Links to this post
Labels: Collocation, TSM 5.5, TSM server
Saturday, August 23, 2008
Mislabeled Tapes Headache
I am periodically running into a situation where TSM will check in our tapes as private or relabel them to private, causing me headaches until I get the tapes status updated. So how do you identify the tapes that are mislabeled? Well if you have setup a library controller instance (which I recommend even if you will only have one instance for clients) then this script should work for you. What you will find when tapes are mislabeled is that they will show the library controller as their owner, will have a NULL value for LAST USE, and will of course be in private status. So a simple select statement can identify them for use.
select VOLUME_NAME from LIBVOLUMES where volume_name not in (select volume_name from volumes) and status='Private' and last_use is NULL and owner='
If your library uses different types of media (LTO-2 and LTO-3) and you have different volume label series for them you can add another filter to further refine the results. For example my LTO-3 tape labels all start with L3 so I use:
select VOLUME_NAME from LIBVOLUMES where volume_name not in (select volume_name from volumes) and status='Private' and last_use is NULL and owner='
Once TSM has generated a list you can then run it through a while loop to reset their status or do further refining of the list if you like. If you are proficient with scripts you can automate the whole process and make life a lot easier.
Posted by Chad_Small at 8/23/2008 0 comments Links to this post
Labels: Checkin, Problem-Solving, Select
Wednesday, July 23, 2008
TSM Admin - Dallas, TX
Posted by Chad_Small at 7/23/2008 0 comments Links to this post
Thursday, July 17, 2008
Rebinding Archives
I would like to thank Nate Tade for allowing me to link to his article on how to extend (rebind) the retention for archives due to expire. I haven't had to extend archives so this is a good "How To". You can find the article by clicking the title of this post or going here.
Posted by Chad_Small at 7/17/2008 0 comments Links to this post
Wednesday, July 16, 2008
Phantom Drive
We recently experienced an issue with a drive that we could not remove or force delete. What was happening is that TSM continually tried to dismount a volume from this drive but failed. The tape it was trying to dismount was in its home slot and not in the drive and the drive showed idle in ACSLS. TSM would not let us remove the path for it so we could not eliminate the problem. We tried a reboot and the dismount retries came up with the TSM server and NOTHING could get rid of the issue. Even turning the drive off in the library did not eliminate the "phantom" dismount attempt by TSM (We even removed the device from AIX to no avail). So did my manager finally find to be the issue? It turned out to be an incorrect WWN for the drive. How it got changed we have no idea...but it did and it caused days worth of headaches and flooded the activity log with errors. So it you ever come across a "phantom" drive check the WWN and make sure you don't suffer as we did.
Posted by Chad_Small at 7/16/2008 0 comments Links to this post
Subscribe to:
Posts (Atom)
0 comments:
Post a Comment