I put together a lengthy document outlining different upgrade scenarios for going from 9.2.x, 9.3.x, 9.4.x and 10.x to 10.2. I hope you find it useful. Please let me know if you have any questions.
Yep, the first option is what I intend to accomplish. I´m going to install a fresh Spectrum in a fresh hardware and Linux OS.
Then, I´m going to upgrade old one to 10.2.3 and the next step is save and load SSdb at the fresh Spectrum.
Does this all data move I must to do ? I mean, all events, rules, configurations, models, topology, GC´s, etc will be at this new one Spectrum after SSdb load ?
Thank you again.
If you are just looking to upgrade Spectrum and move to a different OS, you have 2 options:
a. Upgrade in place to 10.2.3 (or 10.3 once released)
b. Install on the new hardware - make sure the Spectrum release is the same as the original configuration
c. Save your SSdb on the original setup.
d. Load your SSdb to the new setup.
a. Save your SSdb on your original setup and unzip it and rename it to dbsavefile.SSdb
b. Put that file on the new OS in the $SPECROOT/SS directory
c. Run the 10.2.0 install and specify the $SPECROOT and then run the 10.2.3 install (or just run the 10.3.0 install once released).
Both processes do essentially the same thing. The difference being that in the first configuration you will have SS down time on the original setup while you upgrade it.
Thank you. This is new for me, I mean, to all this tasks. Are there something I need to be aware in order to avoid issues ?
For example, in order "to export" information from the older Spectrum I need to upgrade it until a version compatible in some way to the new one, right ?
This old one is on 9.4.0.
Yes, that will be fine. The SSdb save file is not operating system dependent. So you can save it on one OS and load it on another.
Hi Jason. Very helpfull your document. I have this scenario here: upgrade from a 9.4.0 in Windows to most recently version in Linux. What I´m planning to do: upgrade 9.4.0 until 10.x in order to export db to a fresh installation of the most recently CA Spectrum version. What do you think about ?
Is there a firewall between those SS? Sounds like ports might be blocked…
the old spectroserver dss is on 9.4.4 and the new fresh installation is on a new server farm running 10.2.2
This was the result this morning :
spectrum@sedca001012ssp:/home/Spectrum/SS-Tools : ./modelinggateway -vnm Spectrodag01 -e Spectrodag01_import10_data.xml
Modeling Gateway export started. Thu, Dec 7, 2017, at 08:36:57 AM UTC
Failed to bind model domain "Spectrodag01": org.omg.CORBA.OBJECT_NOT_EXISTorg.omg.CORBA.OBJECT_NOT_EXIST: vmcid: 0x0 minor code: 0 completed: No
You can run the 10.2.0 and hotfix patch installs on the new server. Once the installs are complete on the new server, run the modeling gateway on the new server, connecting it to the old server:
for example: ./modelinggateway -vnm <nameofoldSS> -user <username> -e <exportfile> -o <outputfile> -d <debugfile>
we want to update now and have to use user option 3 (Fresh Install and Modeling Gateway Export/Import) but I am wondering how this : "Run the modeling gateway export from any 10.2 SpectroSERVER and connect it to the pre 10.2 SpectroSERVER(s)." should work.
Can you explain what to do.
No, the integration does not need to be disabled. Leave it integrated and do the upgrade.
No, sorry but the modeling gateway does not export SPM tests and/or the test results. You cannot get them replicated from 3 to 1 SS. You could select 1 SSdb and then you'd have to manually create the rest that weren't in that SSdb.
We are planning to upgrade Spectrum 10.2.1 from 10.2 ,this setup is integrated with UIM with vmware and server management .Will the integration must be disabled for upgrade or it can be done in online. I hope it can be done without disabling the integration and vmware .Kindly suggest .
Can we migrate SPM Tests and Custom SubView Filelds data using Spectrum Modeling Gateway? If not, what should be the best possible way to get the same replicated from 3 SpectroSERVERs converted into new Single SpectroSERVER.