Recommended method of Upgrade of Management Server from R81.20 to R82 - VSX

[Networks_Team_B]

Hi All,

What is the recommended method of upgrading a Management Server from R81.20 to R82

The SMS manages a number of VSX gateways 

Is the best method a clean install in this environment? Or an upgrade? 

With the Management Servers, would we upgrade the Primary then fail over, and update the Secondary?

[emmap]

Short answer is that a regular in-place upgrade is probably fine, Primary first then Secondary, complete the version upgrade on both before installing JHF. 

Longer answer depends on the underlying hardware, whether it's been in-place'd before, if you're having any issues with it and what does the verifier say when you try it in CPUSE.

[nmelay2]

In addition to what emmap said, IMO, you should perform a clean install :

• if your management server is still using ext3 root and log partitions instead of xfs
• if it's running on a VM or RAID or flash storage (basically anything but an old single-disk server or appliance), and you did not perform a clean install for R81.20 (i.e. your partitions are still misaligned)

[Bob_Zimmerman]

To check for this partition misalignment, use the command 'fdisk -l' (lowercase Lima):

[Expert@SomeFirewall]# fdisk -l

Disk /dev/sda: 240.1 GB, 240057409536 bytes, 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00023875

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      610469      305203+  83  Linux
Partition 1 does not start on physical sector boundary.
/dev/sda2          610470    35696429    17542980   82  Linux swap / Solaris
Partition 2 does not start on physical sector boundary.
/dev/sda3        35696430   468857024   216580297+  8e  Linux LVM
Partition 3 does not start on physical sector boundary.

A system with properly aligned partitions won't have the "does not start on physical sector boundary" messages. It should look like this:

[Expert@SomeFirewall]# fdisk -l
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 400.1 GB, 400088457216 bytes, 781422768 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 01234567-89AB-CDEF-0123-456789ABCDEF


#         Start          End    Size  Type            Name
 1         2048         4095      1M  BIOS boot parti 
 2         4096       618495    300M  Microsoft basic 
 3       618496     33124351   15.5G  Linux swap      
 4     33124352    781422591  356.8G  Linux LVM       

[CaseyB]

I did the clean install on all our firewalls back in 2024 to resolve the partition issue, it was worth it. Policy pushes went much smoother, would recommend.

[Bob_Zimmerman]

Installing jumbos also involves tons of small-file changes, so it's noticeably faster with aligned partitions.

[nmelay2]

Please note though that the reported disk topology can be unreliable, especially on a VM.

ESXi 8.0 VM:

[Expert@SomeOtherFirewall:0]# fdisk -l

Disk /dev/sda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00075223

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      610469      305203+  83  Linux
/dev/sda2          610470    17382329     8385930   82  Linux swap / Solaris
/dev/sda3        17382330   209712509    96165090   8e  Linux LVM

Hyper-V 2019 VM:

[Expert@YetAnotherFirewall:0]# fdisk -l
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 214.7 GB, 214748364800 bytes, 419430400 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 977DE421-0B8F-46A2-9932-25CFC997BED7


#         Start          End    Size  Type            Name
 1           34       612385    299M  Microsoft basic
Partition 1 does not start on physical sector boundary.
 2       614434     16791888    7.7G  Linux swap
Partition 2 does not start on physical sector boundary.
 3     16791889    419430366    192G  Linux LVM
Partition 3 does not start on physical sector boundary.
 4       612386       614433      1M  BIOS boot parti
Partition 4 does not start on physical sector boundary.

Both are still unaligned wrt underlying storage !

[Bob_Zimmerman]

That's a universal problem with hypervisors, though. They lie pathologically.

[nmelay2]

Indeed, that's what they were designed for. 😉
A virtual machine is.. just that!

[Martijn]

Hi,

Physical or virtual SmartCenter?

When performing upgrades to new major versions, we always try to perform a clean install en restore the database.
Make sure you have the latest CPUSE agent and R82 Tools installed on source and target server.

If your R81.20 SmartCenter had a lot of upgrades and hotfix installations in the past, I surely would go for a clean install.

Martijn