rename VSX cluster member

[Philip_W]

Hi Checkmates,

Our customer's wants to upgrade his environment from R77.30 to R80.20.

Problem is: he has a VSX cluster with cluster members named 'fw1' and 'fw2'. After importing the SMS database to a new R80.20 management server the Validations tab tells us that "more than one object named fw1 exists" (the other being a default service FW1).

Long story short: we have to rename VSX cluster member 'fw1' before we can consider upgrading. In my lab I experimented with vsx_util:

- vsx_util add_member to add a Dummy gateway

- vsx_util remove_member to remove fw1

but this can't be used: "A previous remove member operation did not complete for..." because there is no SIC with the Dummy gateway, which also prevents policy installs to the remaining VSX member.

TAC told us to use vsx_provisioning_tool (and to contact Professional Services 🤔), but after reading the documentation and testing some commands I don't see how that would work.

Anyone?

Ph.

[Alejandro_Mont1]

If I remember correctly you when you turn on the following VSX debugs it skips the provisioning process and allows you to make changes without communication:

#fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PING=INFO
# fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_INSTALL=INFO
#fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PULL_SIC=INFO

Make changes to VSX gateway

Disable debugs with #fw debug fwm off

Might try this in your lab to see if it will let you delete.

[Philip_W]

Thanks Alejandro, I'll test it tomorrow!

[Philip_W]

I'm afraid this didn't solve it. Still getting:

"Previous remove member operation was not completed. Run 'vsx_util remove_member' again to resume operation."

I'll dive a bit deeper still maybe removing the whole cluster & recreating it will be the only solution.

[Maarten_Sjouw]

When you run the 'vsx_util remove_member' again, you can abort the previous operation. Then you can try it again.

[Philip_W]

Going to test further with TAC.

I'll post the solution here, maybe it will come in handy for someone else later on.

[Raf_Brands]

We now created a procedure for the rename in lab:

1. Add dummy node with "vsx_util add_member"
2. Remove the original node with "vsx_util remove_member"
   This will generate an error regarding SIC communicatio
   
3. Edit '$FWDIR/conf/objects_5_0.C', find the dummy gateway object and related child objects and change the status and SIC information
    => Change 'connection_state (uninitialized)' to 'connection_state (communicating)'
    => Change the ':sic_name ()' to a normal value ':sic_name ("CN=Test_tmp,O=gw-2c1401..962djh")' in our test
    => For the child object, in this test there’s only one VS named VG1, so the corresponding sic_name is ':sic_name ("CN=Test_tmp_VG1,O=gw-2c1401..962djh")'
   
4. Run 'vsx_util remove_member' again to remove the original node, this will generate another error (not being able to communicate with the dummy node)
5. Reset or reïnstall the original node (in our lab we used 'reset_gw' in 'vsenv 0')
6. Following sk101674, edit '$FWDIR/conf/objects_5_0.C'
   => find :operation_type (add_remove_member) and delete the blocks where the status is not OK [:status (OK)]
   => Save the file and exit
   => Remove the SmartConsole cache and restart the checkpoint services:
        cd $FWDIR/conf/
        rm CPMILinks*
        cpstop
        cpstart
   
7. Add the original node again under the new using 'vsx_util add_member', this should run ok now
8. Restore the configuration on the renamed node using 'vsx_util reconfigure'
9. Remove the dummy node using 'vsx_util remove_member'
10. Verify in SmartDashboard
11. Test policy push

We will keep this procedure as backup scenario for production, for production we will create a VM with with 10 nics and add this VM as a third node while reinstalling the original node.

Any feedback is welcome!