I’m upgrading one of our clusters this week from 10.2.4 to 10.3.x then on to 10.4 CU5. During the upgrade to 10.3.x, when performing the VerifyClusterPorts.dmupgrade, I’m getting errors related to slnetipc shown in the first screenshot below.
I’ve checked the items that would normally cause us issues such as is NATS running, are ports 8004, 4222, 6222, and 9090 opened up, etc and didn’t see any problems. I dug a little deeper and found a reference to slnetipc in the SLClient logs. The second screenshot below shows what looks to be a good connection including a ConnectionID. The third screenshot shows the error. Any help would be appreciated.
Hi Joe – Subscribing to get more insights from the community.
I’ve just retrieved this page if it can help:
https://docs.dataminer.services/user-guide/Reference/DataMiner_Tools/VerifyClusterPorts.dmupgrade.html
The tool was released for 10.2.0 & 10.2.5 – worth gathering confirmation it is valid for 10.3.x too (should be) as the last package update was in 2022 (haven’t used it in recent times).
From your screenshot (2nd line), it seems the URI for SLNETIPC is not autodetected, hence the procedure might be failing for that.
If the cluster is for staging and not too risky in your environment, you may able to perform a back-up and decide to progress – the last section of the documentation page reports the following:
- While this is not recommended, it is possible to force a DMA to upgrade even if not all ports are reachable. To do so, create a custom VerifyClusterPorts.LastRun.xml file in the folder C:\Skyline Dataminer\Upgrades\Helper\VerifyClusterPorts, containing Success = true and a recent timestamp, as illustrated below. Note that the LastRun.xml file is only valid for 10 days.
HTH
Thanks Alberto. This is our smallest system with only 2 DMAs in the cluster, but it is in production. I am connecting via localhost, not the DNS name so that is something to try. I had also seen another post for a different issue where they created a custom VerifyClusterPorts.LastRun.xml file as you had mentioned, and it worked well for them. You’ve given me several options to try. I’ll schedule a change request for tomorrow and will try your suggestions starting with the DNS name and will try creating the custom VerifyClusterPorts.LastRun.xml file if the DNS name doesn’t solve the issue. I’ll post which option was able to resolve our issue. I appreciate it.
Hi Alberto. I went ahead and attempted the upgrade again this afternoon. I decided to connect the Cube Client using the IP address instead of localhost per your suggestion. The other change from Monday was that I skipped the VerifyClusterPorts package altogether. Ryan Reuss had heard I was having issues and mentioned the verifications that this package performed were built into the upgrade packages from 10.3 on and that it wasn’t needed. The upgrade to 10.3 and then to 10.4 CU5 completed without any issues. Thanks for your help on this. I appreciate it.
Can I ask how many servers are in the cluster & if you’re upgrading all of them at the same time? I seem to recall the “VerifyClusterPorts” tool needs this option enabled to run successfully.
The error, however, would rather point towards name-resolution – so that “http://SLnetIPC” seems unknown in your setup.
Are you launching CUBE via localhost (ConnectedHost = LOCALHOST)?
Do you get the same if you use a DNS name for the cluster or the IP address of a DMA?