per Alex's suggestion, i'll put the export command in the dsmcad start script.
but it
appears linking the TSM libcurl.so.4 library to the OS's fixes the problem, see
below.
but, this feels like hack and i don't know what issues this may cause. any
thoughts?
to me it looks like a conflict betw
Trying to grep that stuff out of the logs is a nightmare.
And it doesn't' cover the case where a VM gets vmotioned to a different ESX
host, and for some reason that host wasn't set up to find and backup all VM's
on it.
So I"ve been tackling it from the opposite direction:
select filespace_
Including VE 6.4!
Thanks IBM!
http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_sm/1/897/ENUS5608-E01/index.html&lang=en&request_locale=en
Wanda Prather | Senior Technical Specialist | wanda.prat...@icfi.com |
www.icfi.com
ICF International | 401 E. Pratt St, Suite 2214, B
Here are the announcements letters for TSM 6.4 and FCM 3.2:
TSM 6.4 Announcement:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=897/ENUS212-382&appname=USN
FCM 3.2 Announcement:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfi
Kinda what I figured.
Thanks for all the responses.
On Thu, Oct 4, 2012 at 8:34 PM, Prather, Wanda wrote:
> I think there is just not a good way to do this from the server end.
> Since these are apparently well-known clients, how about a script on the
> client end?
> perl script #1 wakes up at t
There's something surprising. Clients and DP agents will be at 6.4 level while
the server will stay at 6.3.3 level.
I'm wondering about the way TSM for VE will do progressive incremental (and
restore)...
Let's wait until november 16th!
Erwann "Prather, Wanda" a écrit :Including VE 6.4!
Than
Tsm server 6.2.2 running on RHEL v6 with a 3494 library and 8 ts1120 drives.
Was doing some checking on tape inventory and usage for one of our tsm servers.
A
Select count(*) from libvolumes
Shows 298 volumes in the library.
Checking volhistory for database backup volumes shows 3 tapes in tha
I had a similar problem, did the checkout/checkin and got them into scratch
status.
But, later discovered the internal tape label could not be read which caused
them to return to Private.
Opted to remove them to the "old tape shelf" above my desk.
---
The most obvious reasons would be a tape operator running a check-in script
instead of a label script or checking in with a status=private instead of
status=scratch.
TSM will not initialized a tape with data it knows about, so checking them out
and labeling or checking back in as scratch (which
Some information on how to infer that information is available in the
TSM-VE Deployment Guide:
https://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Tivoli+Storage+Manager+for+Virtual+Environments+Deployment+Guide
Thanks.
Regards/Pozdravi, Gergana
| | ~\\ ! //~
| | ( (
10 matches
Mail list logo