Wrong VCENTER connection when loading the browser to TDP for VMware
Hello This week we upgrade our VMware environment from version 5.1 to 5.5. We backup this environment with TDP for VMware version 7.1.0.2. I register the new Vcenter with: register_vcenter.cmd XXX.XXX.XXX.XX adminuser adminpassword 9080 register_vcenter.cmd XXX.XXX.XXX.XX adminuser adminpassword 9081 (when XXX.XXX.XXX.XXX is the IP of the new VCENTER) Stop and start the services : Data Protection for VMware Web Server Service When I load the VSphere client with the new IP (of new Vcenter) , see the Tivoli Data Protection for VMware plug-in . Everything works fine backup , restore . instant access restore etc …… But when I load from the browser:https://YYY.YYY.YYY.YYY:9081/TsmVMwareUI/ I always rich the OLD Vcenter (clean cookies etc etc …) I double check the vmcliprofile is O.K , we keep the same configuration (Vcenter Node , VMCLI Node , DataCenter Node ,DataMover Node). As I said before from the VSphere client works fine see all the restore and can run backups from the new Vcenter and also automatic schedule backups works. I miss something's but don't know where ! Help please Best Regards Robert
db2osconf, where is it?
Attempting to check and if necessary tune my tsm servers. All are RHEL 6.1 and tsm 6.2.5. In the perf guide it references the db2osconf command. However, I find no such beasty on either of my servers. Where do I get this?
Data Protection for VM app
TSM/VE has a Data Protection for VM app that can be loaded on a VM and used to restore individual files from VME backups. It installs from a big installer app. Has anyone extracted just the msi for the file restore app so that app could be auto-deployed with Windows tools? David
Re: TSM for Email
OK, so TSM/Exchange uses an admin id rather than a node id. But it doesn't appear to actually log on using the admin id. That is, it does not know the password to the admin id, only the node id. But if the admin password is expired, the process fails. Mysterious stuff. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Del Hoobler Sent: Wednesday, September 03, 2014 12:50 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM for Email Hi David, This has to do with the fact that Exchange uses the BA Client for VSS operations through a proxynode relationship. A proxynode relationship requires an admin id with node authority. http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.srv.ref.doc/r_cmd_authority_grant.html?lang=en Thank you, Del ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 09/03/2014 12:14:01 PM: From: David Ehresman david.ehres...@louisville.edu To: ADSM-L@VM.MARIST.EDU Date: 09/03/2014 12:14 PM Subject: TSM for Email Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU I have a set of exchange backups that seem to be failing because the password for the admin associated with the node has expired. Why is it using the admin user rather than the node user? 09/02/2014 22:32:30 ANR0406I Session 481168 started for node DPMBXT01 (TDP MSExchg) (Tcp/Ip exmbxt01.it- servers.louisville.edu(2008- )). (SESSION: 481168) 09/02/2014 22:32:30 ANR0397I Session 481168 for node DPMBXT01 has begun a proxy session for node EXDAGT01. (SESSION: 481168) 09/02/2014 22:32:33 ANR0470W Session 481170 for administrator DPMBXT01 refused - administrator password has expired. (SESSION: 481170) 09/02/2014 22:32:33 ANR0399I Session 481168 for node DPMBXT01 has ended a proxy session for node EXDAGT01. (SESSION: 481168) 09/02/2014 22:32:33 ANR0403I Session 481168 ended for node DPMBXT01 (TDP MSExchg). (SESSION: 481168) more... (ENTER to continue, 'C' to cancel) 09/02/2014 22:32:36 ANR2579E Schedule IT-EX-INCR-WED in domain IT-NR for node DPMBXT01 failed (return code 418). (SESSION: 481053)
Re: orphan libvol
Did you query the volume history on the library client? Perhaps this is a dbbackup, which wouldn't show up in `q vol`. - Cameron Hanover chano...@umich.edu When any government, or church for that matter, undertakes to say to its subjects, this you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression, no matter how holy the motive. --Robert A. Heinlein On Aug 28, 2014, at 9:33 AM, Rhodes, Richard L. rrho...@firstenergycorp.com wrote: Hi, We upgraded our 3584 libs to new drives, and are in the process of converting to new media. I have a orphan libvol - a library manager libvol for which there is no library client volume. LIB MGR libvol - private, owned by TSM5 ./run_cmd.ksh tsmlm2 q libvol 3584isoc j03829 3584ISOCJ03829 Private TSM52,823 3592 LIB MGR volhist ./run_cmd.ksh tsmlm2 q volhist | grep -i j03829 05/29/12 09:09:12 REMOTE 3584ISOC-TAPE J03829 TSM5 LIB CLIENT vol - NONE ./run_cmd.ksh tsm5 q vol J03829 ANR2034E QUERY VOLUME: No match found using this criteria. Now, this TSM5 instance has NO TAPE AT ALL. It was migrated to DataDomain file vols and the tape environment was dismantled. I can just checkout libv 3584isoc J03829 and remove the tape from the lib, and it's gone. But I want to make sure TSM is clean. So I did the checkout, then tried to check it in as SCRATCH. TSM refused to perform the checkin, throwing this error: ANR8443E CHECKIN LIBVOLUME: Volume J03829 in library 3584ISOC cannot be assigned a status of SCRATCH. I then checked it back in as PRIVATE and it went back to being a libv owned by TSM5. Q) Is it ok to simply check out this libv and forget about it? It seems that if I do this, I'm leaving something in the libr mgr that should be cleaned up. Thanks Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: 7.1 on Linux quirk
You don't really mention why you need to start TSM in the foreground, but if that is a requirement and you need to leave your terminal, why not use `screen`? - Cameron Hanover chano...@umich.edu Reminds me of my safari in Africa. Somebody forgot the corkscrew and for several days we had to live on nothing but food and water. --W. C. Fields On Sep 2, 2014, at 10:04 PM, Sergio O. Fuentes sfuen...@umd.edu wrote: Has anyone come across this particular scenario. I'll be opening a PMR for this if my troubleshooting doesn't pan out. I have a Linux 7.1.0.100 server whose dedupe stgpools I'm migrating temporarily to a NAS array. I'm mounting the stgpools via NFS3 and granted, I'm mounting subdirectories of the same export, but that has not been an issue on another 7.1.0.0 server I have. What I'm noticing is that I start the server in the foreground: ssh server sudo su su - tsminst1 cd instancedir /opt/tivoli/tsm/server/bin/dsmserv It starts up ok, I get the console and I start a migration TO the NFS stgpool (hard mounted, sync and intr defined). After awhile, I close up the terminal with the console in the foreground (because I have to go home or I log out or whatever). When I check on the migration or server later, the server's somewhat responsive, but q stg, q mount, q proc and other commands are seemingly hanging on the NFS mount. It always seems to happen after I close the terminal. Very odd behavior. There's a limitation on NFS backups from TSM clients, but haven't found a similar limitation on servers. And ideas? Thanks! Sergio
DB2 table reorg not progressing
Hi All, During our morning DB2 reorg window, I've been observing a table reorg of the BACKUP_OBJECTS table using the command db2pd -d TSMDB1 -reorg. It starts and later pauses without appearing to do any work. I'm assuming this because 'CURCOUNT' is not incrementing, and remains at '0'. It tends to start and pause twice during the 2 hr. window. There are no correlating entries in the server's TSM actlog , db2diag.log, or dsmserv.err. In fact I see no errors logged about this at all. This has been recurring for the past three days. While we've had a variety of experiences with reorg's of other tables over the past year or so, I've never seen this specific behavior. Is there any recommended way to handle this scenario gracefully (without a server restart), such as issuing a DB2 inplace stop/start or other method? I realize it's not optimal to have client backups running during the reorg window, however, it's unavoidable for us. Our load is typically light at that time of day. Our reorgs have been running without serious problems for the past few months, but I'd be willing to try cancelling all client backup sessions before a future reorg window starts, to see if eliminating this activity makes any difference in this case. Does anyone have a solution for such a scenario they'd care to share? Server details: TSM server v6.3.4.200 (not an upgrade from TSM v6.1) on AIX 6.1; DB2 9.7.6. Thanks in advance! Ruth Mitchell U of I, Urbana, IL
