A brief explanation of the SHAREDLIBIDLE parameter

Posted on by
Reply

It is interesting to see how the purpose of the SHAREDLIBIDLE parameter was changed within TSM over time. Even more interesting is the fact that the SHAREDLIBIDLE server option (which needs to be set in dsmserv.opt) is not mentioned in any of the Administrator’s Reference Guides (either for TSM v5.x or v6.x).

Back in TSM v5.1, the parameter was used in a shared tape environment. It was useful when a library client wasn’t mounting tapes anymore, and the sessions were left in the ‘media wait’ (MediaW) state forever. The reason for it being that mount points were waiting on a dismount that had already occurred, but not signaled (IBM APAR IC35283). By specifying ‘SHAREDLIBIDLE YES’ on the library client, future hangs of this nature should be avoided.

Since TSM v5.2 the parameter is used for a different purpose: two or more servers are sharing a tape library (libtype=shared) and volumes are not left idle for some time on library clients. After a session is completed for a library client, the volume is immediately dismounted. SHAREDLIBIDLE YES forces volumes not to be dismounted, but being left idle in the drives, so they can be used again (when the tape is needed the next time) without an extra tape mount. This way excessive tape mounts and dismounts can be avoided under circumstances where you might need this. In addition to library clients, storage agents could also benefit from this. This behavior is (to my knowledge) described in this IBM Technote only.

This is still the purpose of the SHAREDLIBIDLE parameter in the current release of TSM. It works in conjunction with the MOUNTRetention parameter of the sequential device class.
The default of the SHAREDLIBIDLE server option is NO.

In this entry (the only entry with the keywords “SHAREDLIBIDLE YES”) on the ADSM-L mailing list someone has set the MOUNTRetention parameter of the sequential device class to a value of 9999, but volumes are still dismounted minutes after they’re used. The solution is to place SHAREDLIBIDLE YES in dsmserv.opt and cycle the TSM server.

As an alternative, you can also force a client node to keep its mount points by using the node’s KEEPMP parameter. But that’s just for the duration of the current session.

—- Tommy Hueber

What happened to the “Server-to-Server Storage Pool Volume Transfer”?

Posted on by
Reply

Imagine you’ve got multiple TSM servers (who hasn’t?) which are able to communicate with each other using server-to-server (S2S) communication. You now want to move a client between two TSM servers and all you want to export is the node definition (when there is no data yet or when you are able to start with a fresh backup on the destination TSM server) this is easy enough:

export node NODENAME filedata=none toserver=SERVERNAME

But what if all the data must be retained and you have lots of it, let us say 1 TB. For the sake of simplicity, I will assume this data is, compressed, on just on one tape cartridge. The command, in its simplest form, would be:

export node NODENAME filedata=all toserver=SERVERNAME

This means that on the exporting server the volume with data belonging to this node will be mounted and on the importing server another volume will be mounted. Both the metadata and the actual backup data will be send through TCP/IP S2S communication. Under less ideal circumstances loads and loads of volumes will be mounted, positioned, read, etc, etc. It is not uncommon to have to wait for hours, even days for an export session to finish. In the post “A plethora of exporting methods“, several different ways were mentioned to export in such a way, that it enables a ‘large’ node to backup again within 24 hours.

Dealing with large nodes is a major issue to consider during splitting, balancing or consolidating TSM servers. With TSM v5.5, restartable S2S export has been introduced as a feature. You can now suspend and later restart an export operation. This is a step in the right direction.

But….wouldn’t it be nice to have a feature that allowed you to export just the metadata between the exporting and the importing server and then physically move the tape between the libraries? Of course, this method is only valid for physical tape libraries. This sounds too good to be true, but it actually was on the roadmap for TSM v6.1. Of course: statements of IBM plans and directions are provided for information purposes only and are subject to change without notice, but still….

The mechanism is called ‘Server-to-Server Storage Pool Volume Transfer’ and was listed as a future candidate, so beyond the initial release of TSM v6.1. It’s now 2013, TSM v6.3 is around with v7.1 around the corner.

S2S Storage Pool Volume Transfer will dramatically reduce the time (and bandwidth) required for exporting nodes with loads of data. This future candidate initial functionality, at least for now, looks like it will only work for entire storagepools at a time. After the export of an entire storage pool, you can easily delete the nodes that you do not want.

In the image, and the example above, a volume is physically moved between two servers. In a shared library environment, it might be just possible to checkout/checkin or update the owner of the volume(s) to do the trick. Of course, there are some things to keep in mind here. Because a volume cannot have more than one owner, and thus, cannot have data on it from nodes spread across different TSM servers, the data of one node should be on separate, isolated volumes before the owner can be changed.

Will this require a ‘move data’ before the actual export to consolidate data on volumes? This will (at first sight) destroy the reduced time advantage that is created by this new functionality. Or should a form of collocation be in place before the server-server storage pool volume transfer will work?

All in all; is this, at first sight, a very welcome addition to TSM? Time will tell.

—- Tommy Hueber

Getting started with TSM Studio

Posted on by
Reply

This blogpost describes the installation of Spirit Software Solutions TSM Studio and how to connect to a TSM server to start administering it. TSM Studio and TSM Studio Server both require Windows. The platform on which your TSM server is running doesn’t matter – all platforms are supported.

Below is a description (taken from the Spirit Software Solutions website) about the differences between TSM Studio and TSM Studio Server:

TSM Studio is designed to be an administrative tool (similar to Administration Center but with far more functionality), providing access to the majority of TSM Commands. TSM Studio sources all data directly from the TSM Servers.

TSM Studio Server provides all the Automation, Scheduled Reporting, Operational Reporting, Capacity over time Reports, and Enterprise Dashboards. TSM Studio Servers runs collections as pre-defined intervals from the TSM Servers and stores that data in its own database.

You can download a fully functional version with an included 30 Day Professional License (60 Days in the case of TSM Studio Server) here: http://www.spiritsoftware.biz/downloads. Choose the 32 or 64 bit variant. This blogpost was written using TSM Studio (the administrative tool, without the forecasting, trend analysis, etc.) v2.8.9.0, from January 14, 2013.

Download and double-click TSMStudioSetup2890_32bit.exe, the InstallAware Wizard is now started to guide you through the setup process.

  • Click Next.

  • Select “I accept….”;
  • Click Next.

  • Fill in the “User Name” and “Organization” fields as needed;
  • Click Next.

  • If needed, select an alternative installation location (click “Change”). By default, TSM Studio will be installed in the directory %PROGRAMFILES%\Spirit Software Solutions\TSM Studio.
  • Click Next.

  • If needed, select an alternative program folder;
  • If needed, change the “Install this application for” radio button;
  • Click Next.

  • Click Next;
  • The installation will now start.

  • The installation is now finished;
  • Click Finish;
  • The TSM Studio application will now start.

In the main view, there are 4 tabs: TSM Servers, TSM Studio Servers, VTL Servers and ACSLS. For now, we’ll focus on the TSM Servers tab to start administering a TSM server. The TSM Studio Servers tab will be explained in an upcoming blog post.

  • Right-click “Servers”;
  • Select Add Server.

  • Type in the field “Server Name” the Server Name of the TSM server (if needed, check this with ‘q status’: the SERVER_NAME value has been set by the ‘Set SERVername’ command);
  • Type in the field “Description”: a descriptive name of the TSM server if you wish. This field can be left empty. The TSM Server Name will be displayed in the TSM Servers tab, and not the description;
  • Type in the field “Server Address”: Server TCP/IP port number of the TSM server (if needed, check this with ‘q status’: the servername value has been set by the ‘Set SERVERLladdress’ command);
  • Type in the field “Port”: TCP/IP address or hostname of the TSM server (if needed, check this with ‘q status’: the servername value has been set by the ‘Set SERVERHladdress’ command).

Basically, that’s sufficient information to be able to add the TSM server. Click on OK to add the TSM Server definition to the list of servers. There is no check if the connection actually works and you’ll need to provide logon credentials to the TSM server every time. By creating a new dedicated administrative account or using an existing account you can enable “Auto Connect”. Click on the tab Logon and fill in the fields Userid, Password and Verify (type the password again).

By limiting the privilege class of the TSM administrator account used here, you can create read-only users or users with a subset of credentials in TSM Studio.

We’ll leave the User Profile and Command Routing options as they are, for now.

Click on OK to add the TSM Server definition to the list of servers or click Test Connection to check the Admin CLI Connection. My guess is that TSM Studio users the TSM administrative command line (dsmadmc) or uses the TSM API under the covers. A clue for this is that (connection) errors are logged in the well-known dsmerror.log, but this time in %PROGRAMFILES%\Spirit Software Solutions\TSM Studio.

The connection is now added to the TSM Server tab. By right-clicking the TSM Server name you can start exploring all functions of TSM Studio.

If you have a license key, select “Activate License” from the “Help” menu. Provide your product key and click Activate. As stated, you are able to use TSM Studio for 30 days without providing a product key – that’s a good amount of time to get an impression and a feel for TSM Studio.

—- Tommy Hueber

 

Re-register TSM4VE vCenter Plug-in (after IP address change)

Posted on by
Reply

After the IP address changes on the system where the vCenter Plug-in is installed, a re-registration of the vCenter Plug-in is needed to reflect the new IP address. Otherwise, the vCenter Plug-in keeps trying to connect to the old IP address.

This vCenter Plug-in system can be a dedicated machine, and is being referred to as the “Data Protection for VMware vCenter Plug-in Server”, in most IBM TSM4VE component overview images.

In this particular case, the vCenter Plug-in Server (in essence, an IBM WebSphere Application Server (eWAS) server) is directly running on the vStorage Backup Server (VBS), and not on a dedicated machine. In my experience, such a setup is quite common.

A regular de-installation and reinstallation of the “Data Protection for VMware vCenter plug-in” component of the “Tivoli Data Protection for VMware” package, does not solve the issue. The old IP address is still used. My guess is that this component also holds the “IBM WebSphere Application Server V8.0 – TSMVEplugin”, which needs to be made aware of the IP address change manually. During reinstallation the configuration file with the old IP address is retained and not updated.

I noticed that uninstalling the mentioned “Data Protection for Vmware vCenter plug-in” component of the “Tivoli Data Protection for VMware” package does sometimes, and sometimes does not, remove the vCenter Plug-in. When reinstalled, the vCenter Plug-in keeps referring to the old IP address. A reboot of the vCenter server or VBS server does not help.

In the Plug-in manager, a message such as “Unable to connect to TDP for VMware plugin” is displayed:

The following error occurred while downloading the script plugin from http://<old IP address> of the TDPVE plugin server):9080/TsmVMwareUI/plugin/config.xml:Unable to connect to the remote server

Below are the steps outlined to update the vCenter Plugin-in to reflect (and connect) to the IBM WebSphere Application Server (eWAS) at the new IP address. As stated above, a re-registration is needed after the IP address changes on the system where the TSM4VE vCenter Plug-in is installed.

To do this, two different methods are described. For both methods, you’ll need a vCenter account with administrative privileges within the VMware environment. If one method doesn’t work for you, try the other one.

METHOD #1

  • On the VBS (or the machine where the “Tivoli Data Protection for VMware” package is installed, open the Windows Services applet;
  • Stop the “IBM WebSphere Application Server VX.X – TSMVEplugin” service;

  • Go to the directory;

64-bit Windows:
C:\Program Files (x86)\Common Files\Tivoli\TDPVMware\VmwarePlugin

32-bit Windows:
C:\Program Files\Common Files\Tivoli\TDPVMware\VmwarePlugin

Linux:
/opt/Tivoli/tsm/tdpvmware/common/scripts

The remainder of this article is written for Windows; check the manual for Linux (you’ll need ../java –jar reg.jar).

  • Unregister/register the vCenter Plug-in;
    • unregister_vcenter.cmd <vcenter hostname> <vcenter user ID> <vcenter user pw> <old IP address>
    • register_vcenter.cmd <vcenter hostname> <vcenter user ID> <vcenter user pw> 9080 (or another GUI Web Server Port)
  • Start the “IBM WebSphere Application Server VX.X – TSMVEplugin” service;
  • Open vCenter and check the TSM4VE vCenter Plug-in.

If the vcenter hostname specified is a DNS name, note that the first DNS server is always queried. No cache involved.

Just to be sure, check the config.xml file in C:\IBM\tivoli\tsm\tdpvmware\ewas\profiles\TSMProfile\installedApps\tsmCell\TsmVMwareUIEAR.ear\TsmVMwareUI.war\plugin. It should reflect the new IP address.

METHOD #2

For method #2, you’ll need VMware’s Managed Object Browser (MOB), as this cannot be done directly from the vSphere Client software. The MOB is a GUI that “allows you to navigate the objects on a server and to invoke methods. Any changes you make through the MOB take effect on the server”. Check the VMware vSphere Documentation Center for more information.

Remove the TSM4VE vCenter Plug-in:

  • In a browser window, open a connection to https:\\vcenter\mob;
  • Log in with administrative privileges;
  • Under “Properties”, click content;

  • Under “Properties”, click ExtensionManager;

  • Under “Properties”, locate the extensionList line, that relates to the TSM4VE vCenter Plugin. It follows the naming format “extensionList[com.ibm.tsm.tdpvmware@<VBS server name>. You might click the line to gather more information. Note down the text between the brackets and the quotes – you’ll need it later;
  • Under “Methods”, click UnregisterExtension;

  • In the “Value” field, type the text between brackets;
  • Click Invoke Method;
  • The message “Method Invocation Result: void” should be displayed. If it does, the TSM4VE vCenter Plug-in was successfully removed and is no longer visible as a value in the extensionList of the ExtensionManager (see the previous steps). Also, the icon is removed from Solutions and Applications. and, it is removed from the Plug-in Manager (in vSphere: Plug-ins à Manage Plug-ins).

Now you can reinstall the TSM4VE vCenter Plug-in (“Data Protection for Vmware vCenter plug-in” component of the “Tivoli Data Protection for VMware” package):

Sources for this article:
Removing the VE Plugin from ‘Solutions and Applications’
Steps to unregister and register TSMVEplugin to vCenter Server

—- Tommy Hueber