A customer arranged a maintenance window to change their ClusterXL R82 T60 to a VSNext running the same version.
The outage was actually minimal as we began with one cluster member, recreated the structure in VS1, attached VSW and so on.
After the change was completed, we noticed that we didn't create the VS with more than one instance, and as it's a DC-grade Quantum series with only one VS (beyond VS0) representing the previous ClusterXL architecture, we increased that count from the WebUI.
The chassis went then Active/Down instead of Active/Active with the "VSX" pnote listing a CoreXL issue. Traffic would still pass.
Reboot either member didn't help and traffic wasn't lost during the "failovers".
The solution was actually to remove member B so that it goes FCD, put it back in the VSNext, then do the same for member A.
Activating auto-clone also caused a reboot loop, fixed until it was turned off.
After this, cluster came back as Active/Active and green in SC, however with a non-blocking pnote on member A, Interface Active Check (IAC).
We couldn't find why, all releavnt interfaces are up and connected, bonded, shown as OK in insights and ASG commands show that all is fine there, maybe something cosmectic. It was getting late so we did more tests, including reboots, and everything went back OK but still wit the IAC warning.
So, I suppose we hit a local condition at the time of core count change and it is supported to do so after VS creation. VSNext is still new for us so we don't have all the experience and "little tricks to know" like with VSX for instance.
Why is the pnote still called VSX by the way?
Of note, we did another deployment with the core count increased at VS creation and didn't encounter any issues there.
