Forgot to mention that I have tried using TSM (Tivoli Storage Manager) client on Solaris againest a ZFS file system. From what I can tell it works fine… I have backed up and restored some files with it. When looking at the TSM Server it lists the file system as “unknown”, but so far everything has been ok with it.
Since i have not had a chance yet to look at the new 5.3.3 client to see if/how they fixed the zones problem I will post how I did it.
First off, for what ever reason IBM/Tivoli decided that the config files (dsm.sys/dsm.opt) should go in /usr/bin. Why I don’t have a clue but that is not a place where they should go. What is even worse is that when you install the client it puts symlinks to /usr/bin/dsm.[opt|sys] in the /opt/tivoli/tsm/client/ba/bin directory.
/opt/tivoli/tsm/client/ba/bin> ls -la dsm.*
lrwxrwxrwx 1 root bin 33 Dec 21 08:21 dsm.opt -> ../../../../../../usr/bin/dsm.opt
-r--r--r-- 1 root bin 782 May 18 2005 dsm.opt.smp
lrwxrwxrwx 1 root bin 33 Dec 21 08:21 dsm.sys -> ../../../../../../usr/bin/dsm.sys
-r--r--r-- 1 root bin 971 May 18 2005 dsm.sys.smp
What is even better is how they make the symlinks… Any ways to get TSM to work in zones, what I did was change the order the symlinks are. I put the actual config files in /opt/tivoli/tsm/client/ba/bin and then did a symlink in /usr/bin to the /opt/tivoli/tsm/client/ba/bin directory in the global zone (as the /usr filesystem in the non global zones are read only), so now I have this:
/usr/bin> ls -la dsm*
lrwxrwxrwx 1 root root 37 Jul 22 2005 dsm.opt -> /opt/tivoli/tsm/client/ba/bin/dsm.opt
lrwxrwxrwx 1 root root 37 Jul 22 2005 dsm.sys -> /opt/tivoli/tsm/client/ba/bin/dsm.sys
This way each zone can have their own dsm.[opt|sys].. There is one “gotcha” with this method, make sure you back up your files before you upgrade the client. I am not sure at the moment whether they would be removed if you upgrade the client or not. Technically the files (dsm.[sys|opt]) should go in /etc and then symlinks from /usr/bin and /opt/tivoli/tsm/client/ba/bin to them.
N.B. This is probably unsupported by IBM and you use at your own risk.
IBM has finally!!!!! released a TSM Client for Solaris X86 with the release of Client 5.3.3.. Only supported on Solaris 10, and no zones/zfs support but it is finally out…. I will test but I think I can get it to work on Zones the same way I did the one for Sparc that was not supported in zones.. Pretty easy fix, will post info if it works later.
Since Tivoli (IBM) has not ported a TSM Client to Solaris X86 yet, (Even though I was at IBM’s Austin Campus last year talking with the Tivoli people and even offered to port the client on my Laptop while I was talking to them.) There is a very unsupported way to back up a Solaris X86 machine to a TSM server. (Note I have not tried this with any version of Solaris greater than Solaris 9 yet). The first thing is to find the very old ADSM client for NCR MP-RAS, the one I am using is version 184.108.40.206, the file name was IP21862.pkg. This will install on Solaris, but you also have to do some other stuff to make it work:
ln -s /usr/lib/libXt.so.5 /usr/lib/libXt.so.5.0
ln -s /usr/lib/libX11.so.5 /usr/lib/libX11.so.5.0
Once you do that you should be able to back up your machine (of course you will have needed to configure your dsm.opt and dsm.sys first).
Hopefully IBM will start supporting it soon, as of right now I can’t run any “production” stuff on Solaris X86 because I don’t have a reliable way to make backups. (The above is unsupported and may not work for every one. I have used it and restored files, but your milage may very.)
Note to IBM, Please support Solaris X86, you have many versions for Linux on different platforms, why not support Solaris X86. In addition to Solaris X86 why are you killing TSM support for MacOSX?
While I was trying to wade through ibm.com to find if they are ever going to port Tivoli Storage Manager to Solaris X86, I found this article: Guide to porting from Solaris to Linux on Power. First off let me say, I would never think of doing this, I like Solaris way better than I do Linux, and if I were to port something to Linux, it would not be on Power. (Because I can’t personally afford any IBM Power computers.) Aside from that, the most interesting part is the Summary:
The porting effort from Solaris to Linux on POWER in most cases involves just a recompile or minor changes in compiler/linker switches. However, the design of Solaris and Linux is fundamentally different. Solaris is focused on performance, scalability, and reliability, while sacrificing portability. On the other hand, Linux is designed with portability in mind, and it is supported on almost all hardware platforms available today. The Linux 2.6 kernel, however, has significantly improved performance, scalability and reliability from the 2.4 kernel. As a result, there are some system-specific features available on Solaris that are not available on Linux.
What is interesting is that I have never had a lot of portability problems with going from Solaris to Linux. If you write the software correctly the first time then it should be just a recompile. And when did Solaris start sacrificing portability? If it is anything I have seen it be the other way around. People writing non-portable code on linux and then we have to clean it up to make it run on Solaris or any other OS besides Linux.
What is BrandZ?
BrandZ is a framework that extends the Solaris Zones infrastructure to create Branded Zones, which are zones that contain non-native operating environments. The term “non-native” is intentionally vague, as the infrastructure allows for the creation of a wide range of operating environments.
Each operating environment is provided by a brand that plugs into the BrandZ framework. A brand may be as simple as an environment with the standard Solaris utilities replaced by their GNU equivalents, or as complex as a complete Linux userspace.
BrandZ extends the Zones infrastructure in user space:
* A brand is an attribute of a zone, set at zone create time
* Each brand provides its own installation routine, which allows us to install an arbitrary collection of software in the branded zone.
* Each brand may provide pre/post-boot scripts that allows us to do any final boot-time setup or configuration.
* The zoneadm and zonecfg tools can set and report a zone’s brand type.
BrandZ provides a set of interposition points in the kernel:
* These points are found in the syscall path, process loading path, thread creation path, etc.
* At each of these points, a brand may choose to supplement or replace the standard Solaris behavior.
* These interposition points are only applied to processes in a branded zone
* Fundamentally different brands may require new interposition points
Did you say something about Linux?
The lx brand enables Linux binary applications to run unmodified on Solaris, within zones running a complete Linux userspace. The combination of BrandZ and the lx brand will be productized as Solaris Containers for Linux Applications.
The lx brand is not a Linux distribution and does not contain any Linux software at all. The lx brand enables user-level Linux software to run on a machine with a Solaris kernel, and includes the tools necessary to install a CentOS or Red Hat Enterprise Linux distribution inside a zone on a Solaris system.
The lx brand will run on x86/x64 systems booted with either a 32-bit or 64-bit kernel. Regardless of the underlying kernel, only 32-bit Linux applications are able to run.
We do not support SPARC linux. This might be an interesting community project, but it’s not on our roadmap.
BrandZ/lx is still very much a work in progress. This means that it should be expected to crash at any time, set fire to your datacenter, and kick your cat.
Running BrandZ is fairly straightforward, but installing it requires a significant level of technical expertise and familiarity with OpenSolaris development procedures. We have provided some documentation to help climb the learning curve, but if you are not comfortable BFUing your system (or if you don’t even know what that means :), then you will probably be better off waiting until the project is more polished and user-friendly. You are, of course, welcome to try it out and ask questions on the discussion board, but please understand if we cannot provide detailed, hands-on support.
So hopefully you would be able to run Linux inside of a Solaris Container and not need to port anything to any platform.
As a Footnote to my original search in IBM’s site, why is it that they have a TSM Client for Linux on Power, X86, zSeries and iSeries? Why can’t they do a simple port to Solaris X86? You can’t tell me that there are that many people running TSM Client on Linux that is running on a zSeries Mainframe or an iSeries (AS/400) machine.