Which method would you recommend to upgrade from R80 to R80.20?

[DR_74]

Hello,

I have an "old" R80 management server running on a VM which manages a VSX cluster and several small SMB appliances.

We would like to upgrade to R80.20 and we wonder which method is recommanded:

- CPUSE

- Migrate export/import

Thank you for your advices

Regards

[Jerry]

CPUSE should be fair enough. try and if it failes try another one, there is plenty of options and frankly if CPUSE won't work for you it means there is somethnig "inconsistent" with your DB or the capacity of your hardware/VM does not want to cope with R80.20 *(see spec limitations and req's).

cheers

[DR_74]

Hello,

Yes I tried CPUSE today on a lab VM with same spec as original, and I think I will be short with the disk size...

Think I need to go through migrte export/import

Thanks for feedback

[Jerry]

migrate_export then

unless you're up for playing with df/fdisk  resizing ...

[Timothy_Hall]

I would strongly recommend performing a database migration (i.e. migrate export/import) for SMS upgrades into R80.20 and later so you will get the updated 3.10 kernel along with the new XFS filesystems.  Major improvement in management performance, especially with larger configurations.  In-place upgrades of an SMS with CPUSE into R80.20 will leave the kernel at 2.6.18 and filesystems using ext3.

--
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com

[Jerry]

you are right Tim, I've forgot about the FS at the end ... sorry guys, too many things these days slips over your shoulder 🙂

[Vincent_Bacher]

upgrading using migration tools is always the best choice

[Garrett_DirSec]

Confirming you have reviewed the appropriate section in R80.20 install and upgrade guide.  there is section specific to upgrade of VSX, etc.    link HERE>

I suggest mgmt "upgrade" to always include "migrate export <>" with re-image (especially if you running virtual which makes this wonderfully easy with good fallback options).   In the case of R80.20 and SmartCenter and/or SmartEvent, you'll want to be running XFS filesystem on end result so re-image required.  

the following may come in handy as well depending on your backend storage architecture (single disk, RAID, SAN, etc).

Managing partition sizes via LVM manager on Gaia OS

http://supportcontent.checkpoint.com/solutions?id=sk95566

How to extend partition on Gaia

http://supportcontent.checkpoint.com/solutions?id=sk114115

How to resize XFS partitions in R80.20

http://supportcontent.checkpoint.com/solutions?id=sk131332

[dj0Nz]

I don't know which method is "officially" recommended but I would rather do a fresh install on a second VM and use migrate export/import to transfer your Checkpoint configuration to the new management VM.

If you create a migration network within VMware and place some kind of "NAT Voodoo" between new and old management (two Linux VMs with IPtables and appropriate NAT rules should do the job here), you may run both systems in parallel with same IP and hostname and transfer the export file and other kind of stuff without having to use an additional transfer storage. 

That's the way I do it and it has been working in a couple of migration projects now. The advantage of this approach is that you don't have to touch your productive management. I case things go wrong, you are back with a working environment just by re-attaching the vNICs of the VMs you use.

[Dale_Lobb]

  We are in the process of migrating to R80.20, so I have read tons and tons of SKs and community articles recently.  Unfortunately, I do not remember where I got this, but I do remember one article cautioning about using CPUSE upgrades for major versions. Perhaps someone else can verify what I am about to say:  Apparently during a CPUSE major version upgrade, the root partition of the system gets replaced. and while the CPUSE upgrade will do the migrate export/import for you, changes you may have made to configuration files or other changes to the root partition will be overwritten with the vanilla files and settings from the new major version.  So, basically, do not assume that CPUSE will carry all changes in place.  Take inventory of all your changes and make ready to re-apply them to the upgraded version, whether that upgrade is performed via CPUSE or by by new install with manual migration.

  One other thing: R80.30 is supposed to be GA any day now, so you may want to wait for it.  We have tentatively decided to wait for R80.30 GA to finish our migration because of the new features (we really want the SNI functionality for HTTPS inspection, which is supposed to be in R80.30, but not yet in R80.20).