I'm attempting to merge 8 x Spectrum 9.4 landscapes down to 3 x Spectrum 10.x landscapes using modelling gateway as specified in the docs.
Each of the landscapes I am attempting to merge from is teetering on the limit for 32 bit and each one has between 90k and 130k model count.
I have exported just the models, connections, port info, annotations and GCs from one of the 9.4 landscapes and have attempted to import into the new 10.x one. Problem is after 10 minutes of "import will continue if no new models activate in x minutes" the import moves on with a good chunk of the devices still not activated.
As those models aren't activated, the connectivity import part doesn't work orrectly and we end up with a bunch of models with no links between them where there should be. These are all primarily 3Com and Juniper devices and just manually running "discover connections" on each container doesn't model them properly as there's spanning tree and other things involved.
I'd like to give the import process a good 1/2 hr or more to ensure all models are activated before moving on to the next stage. It may not get all of them in perfectly even after that, but the number of missed links should be significantly lower.
The only other alternative I'd have is to let the import run as is, then devise some sort of script to parse the error log and then re-link the models via CLI (REST is a mystery to me!)
Does any one have any ideas how I can make this work with as few errors as possible?
Honestly I'm not sure if this will work, but it's definitely worth a shot:
In the <SPECROOT>/SS-Tools/.modelinggateway.dtd is the following timeout value you can try changing to see if it helps.
<!ATTLIST Import model_activation_time CDATA "5">
I did find that and have been experimenting:
That doesn't appear to do much. I have set it to 10 minutes, 30 minutes, 60 minutes. When I run the import after about 2 minutes of running, the "The import process will continue if no new models activate within x minutes" messages start and the 10 minute timeout still seems to apply.
I've also tried increasing and reducing the number of threads for the process and that seems to help a bit if I reduce from 50 to around 25-30 but I still end up with a few thousand errors.
It's most frustrating. How are we supposed to merge databases that are getting too large if we can't control the timeouts and polling during that process correctly?
I was about to suggest to increase the number of activation threads on the machine, temporarily, while you execute the import. I do remember having tested this out when the Beta for 10 was ongoing. I had problems with devices that were not responding at the time that I tried to import the XML from my old systems. I have it now at 600 set. That would definitely speed up the process.
I was considering suggesting you exactly what Jay was saying. If that doesn't work, open an issue with support, as I think it should work.
In the VNM, model activate threads is already set at 600 and it’s only peaked at 104! Something's definitely not right.
Please open a case with CA Support if this problem is still acute