SystemTap

Guys, that’s not funny ay all. To tell the truth, I’ve never used SystemTap myself but always treated it as a valid option when your on Linux as there is no dtrace. But hey, read another outstanding review from Brendan Gregg and decide yourself if you could trust it. Just a short excerpt:

To write this post, my system has hung when running SystemTap more than six times (I lost count), requiring a power cycle each time. While this system seems more brittle than others on which I’ve run SystemTap (I usually have to run more than just disktop.stp to hit a crash), I still don’t feel safe using SystemTap in production.

Read the rest – it’s really worth it.

HTnM data migration between Windows and Linux

Sometime ago I was trying to migrate HTnM data, more precisely HTnM agents datastore history information, from Windows to Linux and want to share my story. Migrating HTnM configuration and its data from Windows to Linux is very easy, just follow the documentation steps verbatim. But moving historical data from the HTnM agents, whether it’s RAID or SAN, is a different thing. One may think that it’s a straightforward operation, well it really is, but the documentation doesn’t quite agree on that.

OS groups that can be migrated
OS groups are defined as follows for the Tuning Manager series. Store database migration can only be performed for the same OS groups.

• Windows groups:
• Windows Server 2003 (x86)
• Windows Server 2003 (x64)
• Windows Server 2008 (x86)
• Windows Server 2008 (x64)
• HP-UX groups:
• HP-UX 11i V2 (IPF)
• HP-UX 11i V3 (IPF)
• Solaris (SPARC) groups
• Solaris 9 (SPARC)
• Solaris 10 (SPARC)
• Solaris (X64) group:
• Solaris 10 (X64)
• AIX groups:
• AIX 5L V5.3
• AIX V6.1
• Linux groups:
• Linux4 (x86)
• Linux5 (x86)

Moreover, it says that this is unsupported (I have opened the case in HDS and they confirmed my sneaking suspicions). Period.
Thankfully, I had some spare time to prove the documentation wrong. Sounds over-confide, I know. ;-)
Anyway, I tried to pretend that I hadn’t read that part that stated that this was unsupported and went through the steps as I was migrating data between Windows-based machines. First, I boldly tried to migrate directly from Windows (HTnM 6.4) to Linux (HTnM 7.1) and everything went very nice until I tried to restore the data from RAID agent on Linux server. When I ran jpcrestor tool I was told that data model of the agent on the migration destination (Linux server) differed from the migration source (Windows) version. JFYI, HTnN ver. 6.4 uses data model ver 7.6, whilst HTnM ver. 7.1 has data model ver. 8.0. For me it meant that before being able to migrate the store database I had to convert from older to newer version. Hitachi provides a special tool just for that:

# /opt/jp1pc/tools/jpcdbctrl dmconvert -d /tmp/export/
KAVE05847-I Data model conversion of backup data will now start. (dir=/tmp/export/)
KAVE05099-E An internal command terminated abnormally. (/opt/jp1pc/bin/jpccvtmdl -sdict "/tmp/export//STDICT.DAT.bak" -ddict "/tmp/export//STDICT.DAT" -stdir "/tmp/export/" -wkdir "/tmp/export//cvtwork" -directdbdir "/tmp/export/")
KAVE05849-E Data model conversion of backup data ended abnormally. (dir=/tmp/export/)

As I mentioned before, I opened a case with HDS and was “pleased” to hear that what I was doing was unsupported. So I was on my own. But I didn’t give up. I’d decided to upgraded HTnM on Windows to version 7.1 and repeat everything once again. To my surprise, since I didn’t have to mess around with converting data model to the same format, agent’s data were restored swimmingly. Important note. I had to run dos2unix against jpcsto.ini file since it contained Windows CRLF line terminators which is expected since I was migrating from Windows server. Once I did that, there were no more hurdles to overcome:

# ./jpcresto agtd /tmp/hdsb inst=uspv-array 
Directory receiving backup data = /opt/jp1pc/agtd/store/uspv-array 
Directory supplying backup data = /tmp/hdsb 
Clearing indexes... 
Appropriate indexes removed. 
Replace in progress. 
Replacing /tmp/hdsb/STDC.DB to /opt/jp1pc/agtd/store/uspv-array/STDC.DB ... 
Replacing /tmp/hdsb/STDC.IDX to /opt/jp1pc/agtd/store/uspv-array/STDC.IDX ... 
Replacing /tmp/hdsb/STDM.DB to /opt/jp1pc/agtd/store/uspv-array/STDM.DB ... 
Replacing /tmp/hdsb/STDM.IDX to /opt/jp1pc/agtd/store/uspv-array/STDM.IDX ... 
Replacing /tmp/hdsb/STAM.DB to /opt/jp1pc/agtd/store/uspv-array/STAM.DB ... 
Replacing /tmp/hdsb/STAM.IDX to /opt/jp1pc/agtd/store/uspv-array/STAM.IDX ... 
Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDS.DB to 
/opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDS.DB ... 
Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDS.IDX to 
/opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDS.IDX ... 
Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_CLPS.DB to 
/opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_CLPS.DB ... 
Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_CLPS.IDX to 
/opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_CLPS.IDX ... 
Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDE.DB to 
/opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDE.DB ... 
Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_LDE.IDX to 
/opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_LDE.IDX ... 
Replacing /tmp/hdsb/STPI/5/2010/1130/001/PI_PTS.DB to 
/opt/jp1pc/agtd/store/uspv-array/STPI/5/2010/1130/001/PI_PTS.DB ... 

... SKIPPED ... 

Replacing /tmp/hdsb/STPD/2011/0726/001/PD_RGC.DB to 
/opt/jp1pc/agtd/store/uspv-array/STPD/2011/0726/001/PD_RGC.DB ... 
Replacing /tmp/hdsb/STPD/2011/0726/001/PD_RGC.IDX to 
/opt/jp1pc/agtd/store/uspv-array/STPD/2011/0726/001/PD_RGC.IDX ... 
Replacing /tmp/hdsb/STPH.DB to /opt/jp1pc/agtd/store/uspv-array/STPH.DB ... 
Replacing /tmp/hdsb/STPH.IDX to /opt/jp1pc/agtd/store/uspv-array/STPH.IDX ... 
Replacing /tmp/hdsb/STPA.DB to /opt/jp1pc/agtd/store/uspv-array/STPA.DB ... 
Replacing /tmp/hdsb/STPA.IDX to /opt/jp1pc/agtd/store/uspv-array/STPA.IDX ... 
Replacing /tmp/hdsb/STPT.DB to /opt/jp1pc/agtd/store/uspv-array/STPT.DB ... 
Replacing /tmp/hdsb/STPT.IDX to /opt/jp1pc/agtd/store/uspv-array/STPT.IDX ... 
KAVE06006-I Restore processing of the Store database terminated normally. 

More than that, when I logged onto HTnM web interface and searched my one year old data from USP-V array – they were all their for my observation. Sweet. What’s the gist of this post, you may ask. Well, not only don’t ever give up but always take every recommendation, even if it comes from a vendor’s support team, with a grain of salt. Peace.

Requiescat In Pace

No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true. Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

Steve Jobs.