Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Kaspars_Zibarts
Authority
Authority

VSX upgrade from 2.6 to 3.10 (R80.40) kernel experiences

Hi!

Those who have upgraded your VSX already to 3.10 kernel (R80.40) - any tips or what to watch out for? We have CP 23800 appliances

If I chose to upgrade instead of clean install and re-configure, does that mean we keep the old filesystem ext3 instead of getting xfs? Has anyone tried CPUSE CLI upgrade with VSX?

Same time changing file system means that rollback will get more complex as you cannot roll back snapshot that was made in different FS, so you would have to re-install 2.6 before being able to restore snapshot.

Anything else? @Magnus-Holmberg  @JasonMcAllister 

0 Kudos
Reply
7 Replies
Magnus-Holmberg
Advisor

We installed from scratch on new hardware when we did start on R80.30 3.10
We haven't done any upgrade on these boxes to R80.40 yet, am still waiting for HFA to be over 100 🙂


When we upgraded before CPUSE via CLI is the way we go for, and we use it regularly for HFA upgrades.
Issue with VSX is if you need to rollback, we used the downgrade for vsx provisioning tool even that is has not been supported untill R81. 

https://www.youtube.com/c/MagnusHolmberg-NetSec
Kaspars_Zibarts
Authority
Authority

I can see that CPUSE upgrade is available and in all honesty if the only difference is filesystem, then I'm not too worried on GWs as FS performance isn't that big of an issue compare to MGMT. Upgrade saves me a lot of time restoring all "small" things like IA tweaks, dynamic objects scripts etc. Plus the benefit of easy rollback with snapshot 🙂

vsxs2-ext:0> installer verify 7
Info: Initiating verify of Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz...
Interactive mode is enabled. Press CTRL + C to exit (this will not stop the operation)
Result: Verifier results Package: Check Point R80.40 Gaia Fresh Install and upgrade Clean Install: Installation is allowed. Upgrade: Upgrade is allowed.

0 Kudos
Reply
Kaspars_Zibarts
Authority
Authority

One thing I am worried about (we do not have a lab to verify...) is the fact that right now 23800 VSX cluster on R80.30 is NOT hyperthreaded and upgrade will force it to change. Wonder if it will affect synchronisation somehow

0 Kudos
Reply
Magnus-Holmberg
Advisor

I wouldn´t care about the filesystem as its a GW and not MGMT, i dont think it gives any benefits that are noticeable on a GW.

Are you guys using VSLS so you can move one VS at the time just for verification etc?
Am using open servers so HT is turned off in BIOS for me so havn´t experience that issue.

Regarding easy rollback, i dont agree really,
As its VSX you are F* as soon as you change the mgmt to the new version.
Then you need to do vsx downgrade (not supported but works 🙂 )
or snapshot back the mgmt server together with the gw.

But i would go for upgarde, with CPUSE as its easiest 🙂

https://www.youtube.com/c/MagnusHolmberg-NetSec
0 Kudos
Reply
Kaspars_Zibarts
Authority
Authority

By easy I meant that I'm on the right SW level with all my tweaks, keys and scripts on the gw instead of doing that all over again 🙂

 

0 Kudos
Reply
JasonMcAllister
Contributor

My OpenServers had HT turned on in BIOS, although I hadn't checked this and historically lead to believe HT wasn't enabled - Alas it was.

However, synchronization didn't seem to complain about the mismatch and MVC worked quite nicely.

My only query was in a thread about the licensing surrounding that.

 

I agree with @Magnus-Holmberg you're probably going to have an easier time with CPUSE method.

I would also avoid using vsx_util downgrade to rollback unless TAC specifically told me to.

Instead my roll back (as my MDSM is on VMWare) is a snapshot prior to upgrade where the VSX database is on the original versions.

Any & all operations performed via vsx_util come with that recommendation to backup first.

0 Kudos
Reply
JasonMcAllister
Contributor

Hi @Kaspars_Zibarts 

I have just finished upgrading 6 member VSLS OpenServer clusters (two of them) from R80.10 to R80.40 and we had decided to go with clean install and reconfigure, although it does take considerably longer.

If I chose to upgrade instead of clean install and re-configure, does that mean we keep the old filesystem ext3 instead of getting xfs?
Yes, you would retain ext3 currently.
CPUSE upgrades are not currently performing the replacement of filesystems to xfs and will retain your ext3 filesystem formats until you perform a clean installation.

Whilst I'm not certain, I suspect that typically this procedure during CPUSE upgrade isn't available as the 2.6 kernel used perhaps doesn't have xfs merged in and therefore fresh installs prepare volumes using 3.10.
I'd be interested to know how that applies if you went from 3.10/ext3 to 3.10 again using CPUSE though, so that'd be interesting to know - But I've never hit a scenario to try.

Has anyone tried CPUSE CLI upgrade with VSX?
Only in lab environments, just to see the results and they meet my previous answer. ‌‌


Same time changing file system means that rollback will get more complex as you cannot roll back snapshot that was made in different FS, so you would have to re-install 2.6 before being able to restore snapshot.
If you're doing a CPUSE upgrade, the filesystem will not be changing and so your snapshots will be the same ext3 formatting.
Unless you mean to revert to a snapshot that has been exported before upgrade and imported back onto the appliance after upgrade, which in itself sounds like it may have more complications than just the filesystem discrepancy.

Other thoughts
The transition from ext3 to xfs operationally has been smooth - I've not encountered issues directly as a result of it but I do not believe there to be a gain on GWs as there is on Management.
Personally, I'm more of a fan of xfs on the whole anyway. I've been accustom to using it outside of Check Point for quite a number of years.


Kind regards,

Jason

0 Kudos
Reply