Skip to Content

Moving from SolutionManager 7 ehp1 stack 22 to a 64-bit virtual environment

I need to come up with a fairly quick answer regarding the issues/tasks involved for an upcoming upgrade.

At the moment we have Solution Manager on a 32-bit system at 7 ehp1 stack 22. We are seriously exploring the option of taking our planned upgrade of ECC (ecc5 to ecc6) to a virtual environment.

What impacts would leaving solution manager on the native 32-bit server have?

What would it take to put the Solution Manager into the 64-bit virtual environment?

I'm continuing to search through docs and notes, but if you could give me a quck thumbnail of issues / benefits / how-to-do-it I'd sure appreciate it as well.

Thanks for your thoughts and ideas!

Laurie McGinley

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Oct 08, 2010 at 02:57 PM

    Hi Laurie,

    We've just gone through a similar move, although we didn't do any upgrades at the same time as we felt it would complicate troubleshooting if there was a problem.

    With regard to the solution manager migration, the main issue for us was that we only had one Solution Manager system and this made planning, testing and documenting the process in advance difficult.

    We use Solman for some 'basis' type functions like EWA, CCMS (CEN), maintenance certificates etc. We don't use it for documentation, charm, business process monitoring. So although the monitoring is important, Solution Manager isn't a critical system for us so we had some flexibility if the migration didn't go smoothly.

    We did a homogenous system copy following SAP's docs to complete the move and largely this worked. As we came across problems we resolved them (e.g. didn't create some scripts across or install some specific scripting tools).

    I have since found lots of entries in Visual Administrator referring to the old hostname and have fixed these as I came across them. (I'm not sure if this is 'standard' or whether the system copy didn't work properly - either way, this is what happened)

    My tip would be to ensure your new system has the same hostname (or resolves to the same IP address in DNS) and runs from the same gateway service. This will ensure you don't have to change loads of RFC's and CCMS / SMD agents etc.

    I'm looking to setup a second Solution Manager for our sandpit systems so we have a system we can use to test independently of the production environment.

    Hope this is of some help


    Add a comment
    10|10000 characters needed characters exceeded

    • Hi Gareth, it sounds like you have a similar usage of solman. The info you provided is very helpful. I figured a homogeneous system copy would be the base of the process. Not having done that with solman on the dual stack tho I was real unsure about what that looked like. Good advice on the hostnames.

      Thanks 😉


      Edited by: Laurie McGinley on Oct 8, 2010 8:19 AM

  • author's profile photo Former Member
    Former Member
    Posted on Oct 08, 2010 at 06:25 PM

    I on the other hand took a different approach. I left my SM alone (on 64bit Linux).

    I tried a system copy, but as management hadn't hired a migration consultant, I couldn't open OSS messages on the attempted


    I attempted to migrate from physical Linux x86_64/db2 to virtual AIX LPAR/db2.

    I had a problem with the unicode Linux export (as AIX uses bigendian unicode and Linux little endian).

    I ended up leaving the Linux SM where it was and installing SM on the AIX lpar, using different SID, system #, hostname and IP.

    I changed the configuration of each ccms agent to have two CENs (this is supported, but you can't use SM scripts to do the setup. I ran SOLMAN_SETUP managed system, first for all my abap systems.

    I then stole the SMD agents from the Linux SM by running sldconf on the agent, and because I don't like the use of load balancing (I only have one JDI in my new SM) I also ran manconf (both to point at the new SM).

    As I now had two SLDs I cross connected the two, so that changes to one were reflected in the other.

    When the SMD agents showed up in agent admin, I ran SMD setup managed system.

    Next I run the Wily agent setup. This required the only downtime - restarts of all my java products.

    Now as I run maintenance (eg to install the recent ST-PI and ST-A/PI) I change the SLD data supplier target (RZ70 or dest SLD_Data_Supplier) but there's no rush as I've removed load from the Linux.

    The AIX virtual has more resource than the Linux, so I've added functionality...

    SMD agents on ERP ABAP to collect change management data for example.

    CHarM and service desk are planned.

    I now have a sandbox SM and a production SM. The sandbox will die at some point (its disk is filling up or its OS RHELV4 won't be supported for a higher level kernel used by next SM)...


    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.