R80.30 upgrade from R80.10

[David_Herselman]

We upgraded from R80.10 to R80.30 this last weekend. The process is well documented, although we wasted time when we got to the global Smart Event server, as detailed below...

Some notes from our experience:

• Preloading kernel module drivers for VirtSCSI and VirtPCI.
• 'R80.30 Management Server Migration Tool' is referenced in documentation as being 'Upgrade Tools'.
• License management via Smart Update is again problematic, use CLI

Preloading kernel module drivers for VirtSCSI and VirtPCI.

Our compute nodes use Linux KVM so we were previously limited in R80.10 to using the VirtIO Block drivers ( /dev/vda). This unfortunately doesn't support TRIM/DISCARD/UNMAP, so we were primarily looking forward to a more modern kernel to gain access to storage using VirtIO SCSI.

We amended /etc/modprobe.conf to include additional drivers:

alias scsi_hostadapter cciss
alias scsi_hostadapter1 ata_piix
alias scsi_hostadapter2 ahci
alias scsi_hostadapter3 virtio_pci
alias scsi_hostadapter4 virtio_scsi

Then rebuilt the kernel:

cd /boot
mkinitrd initrd-3.10.0-693cpx86_64.img 3.10.0-693cpx86_64 -v -f

Implemented Ceph object size aligned (4 MiB) partitioning structure:

Disk /dev/sda: 419430400s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start     End         Size        File system      Name  Flags
 1     8192s     622591s     614400s     ext3                   boot
 2     622592s   9011199s    8388608s    linux-swap(v1)
 3     9011200s  419430366s  410419167s                         lvm

Disk /dev/sdb: 209715200s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start  End         Size        File system      Name  Flags
 1     8192s  209715200s  209706975s                         lvm

We use pvemove and pvextend to separate the operating system and PostgreSQL from logging and temporary file management:

[Expert@fwcpm1:0]# lvdisplay -m | grep -e 'LV Path' -e 'LV Size'; lvdisplay -m | grep -A 3 -e 'Logical extents '
  LV Path /dev/vg_splat/lv_current
  LV Size 195.69 GiB
  Logical extents 0 to 6261:
    Type linear
    Physical volume /dev/sda3
    Physical extents 0 to 6261

  LV Path /dev/vg_splat/lv_log
  LV Size 99.97 GiB
  Logical extents 0 to 3198:
    Type linear
    Physical volume /dev/sdb1
    Physical extents 0 to 3198

We ran in to a problem when we attempted assembling the kernel, booted using a CentOS 7 rescue environment. I assume this to be an undocumented security feature; albeit resulting in one having to disconnect the drive and reattach it using either IDE or AHCI emulation, when assembling the kernel boot image.

Question: Is there a Check Point recovery boot image with which one can package the Gaia 3.10 kernel?

Check Point R80.10 - CPU utilisation - Multi Domain Log Server:

Check Point R80.30 - CPU utilisation - Multi Domain Log Server

Great performance improvement with us running it on Ceph...

'R80.30 Management Server Migration Tool' is referenced in documentation as being 'Upgrade Tools'

Spent way too long puzzling through the wrong tool. The documentation references the required tool as being 'Upgrade Tools'.

https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Installation_and_Upgrade_Gui...

  Upgrading Multi-Domain

    Upgrading Multi-Domain Servers in High Availability from R80.20, R80.10, and lower

      Upgrading Multi-Domain Servers in High Availability from R80.20, R80.10, and lower with Migration

        Upgrading a Dedicated SmartEvent Server

          Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower with Migration:

R80.30 Home Page:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

The tool I wasted time with was the 'Upgrade Tools package', instead of the 'R80.30 Management Server Migration Tool'.

License management via Smart Update is again problematic, use CLI

Running SmartUpdate (connect to domain, menu and then 'manage licenses and packages') reveals every vSec license being attached to the gateway within the domain, for each domain:

The CLI method is ultimately faster and more reliable:

• Connect to the primary MDS server and obtain the relevant CMA IP address by running 'mdsstat'
• Switch to the domain by running mdsenv x.x.x.x
• Remove expiring or expired licenses by getting the signature and then removing it:
  • cplic print -x
  • cplic del <signature>
• Import the new license, eg cplic put -l <file.lic>
• Assign available licenses to gateways: vsec_central_license

Regards

David Herselman

[PhoneBoy]

Thanks for sharing.
I suppose you could always do a fresh install of Gaia in a different VM and mount the relevant filesystems that way, performing whatever steps are required.