- Products
- Learn
- Local User Groups
- Partners
- More
Step Into the Future of
AI-Powered Cyber Security
The State of Ransomware Q1 2026
Key Trends and Their Impact
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
CheckMates Go:
CheckMates Fest
Hi,
I need to perform a full failover of my VSX Cluster XL environment for a maintennace window. (R80.30)
Right now, the VSX cluster uses VSLS but all VSs are active on the same VSX node (member1).
So what would be the best way to force a full failover to the VSX member2?
I read sk56060 which says the best way is "clusterXL_admin down" but in sk95133, it is said that with "clusterXL_admin down" the VS do not become active on the Active Member.
In our case we need to have all VS switched to VSX member2 (included vs0)
Thanks for clarification and help
The proper way to do a controlled failover would be to use the "vsx_util vsls" tool.
Run it on the management server, and connect to the vsx cma/sms to change priority and move the virtual systems.
That's just to configure the distribution of the virtual systems. We don't process traffic on vs0 for our VSX clusters, that's just for management, snmp etc, so a failover there wouldn't be required for normal upgrade operations.
If you must failover vs0 as well, I think clusterXL_admin down in that context is a decent option.
You can always just run 'cphastop'. It's a bit brute force, but should stop clustering entirely on the member where it is run, which will cause the other members to realize it's down and rebalance.
You mentioned you're using VSLS, but all your active contexts are on the same member. That seems odd. Are you sure you're using VSLS and not normal HA?
The proper way to do a controlled failover would be to use the "vsx_util vsls" tool.
Run it on the management server, and connect to the vsx cma/sms to change priority and move the virtual systems.
Hello,
Thanks for the reply.
Does this also failover the vs0? or only the other vs?
That's just to configure the distribution of the virtual systems. We don't process traffic on vs0 for our VSX clusters, that's just for management, snmp etc, so a failover there wouldn't be required for normal upgrade operations.
If you must failover vs0 as well, I think clusterXL_admin down in that context is a decent option.
Actually, we need to perform a failover for a Case.
We were asked to switch everything on the other node (all VS including vs0).
You can always just run 'cphastop'. It's a bit brute force, but should stop clustering entirely on the member where it is run, which will cause the other members to realize it's down and rebalance.
You mentioned you're using VSLS, but all your active contexts are on the same member. That seems odd. Are you sure you're using VSLS and not normal HA?
Yes, VSLS is used as if we are in HA mode. Just in case one day we need to share VS on the different VSX.
Thanks to your answer I was able to play with:
- clusterXL_admin up|down to failover a single VS (1 by 1)
- cphastop to failover everything in 1 command
- vsx_util vsls to switch VS without putting in DOWN state
Agree with this as well. We have always used vsx_util to manually move the VS's until we want them back where they belong. If it is for a case, this sounds like the best and cleanest option.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 24 | |
| 19 | |
| 10 | |
| 9 | |
| 8 | |
| 7 | |
| 6 | |
| 4 | |
| 4 | |
| 4 |
Wed 20 May 2026 @ 11:00 AM (CEST)
The New DDoS Reality: Autonomy, Scale, and the Future of DefenceFri 29 May 2026 @ 09:00 AM (EDT)
Caracas: Executive Breakfast: Innovación en Ciberseguridad – IA y Threat IntelligenceTue 02 Jun 2026 @ 06:00 PM (IDT)
Under the Hood | Check Point SASE: Identity Integration & Access Policy Design Best PracticesWed 20 May 2026 @ 11:00 AM (CEST)
The New DDoS Reality: Autonomy, Scale, and the Future of DefenceTue 02 Jun 2026 @ 06:00 PM (IDT)
Under the Hood | Check Point SASE: Identity Integration & Access Policy Design Best PracticesThu 04 Jun 2026 @ 02:00 PM (CEST)
Deep Dive Webinar: New CloudGuard GWLB Deployment Without NAT Gateways - EuropeThu 04 Jun 2026 @ 07:00 PM (IDT)
Deep Dive Webinar: New CloudGuard GWLB Deployment Without NAT Gateways - AmericaFri 12 Jun 2026 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 47: Continuous Threat Exposure ManagementFri 29 May 2026 @ 09:00 AM (EDT)
Caracas: Executive Breakfast: Innovación en Ciberseguridad – IA y Threat IntelligenceAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY