manager upgrade from r81.10 to r81.20

[Luis_Miguel_Mig]

I am planning to upgrade the firewall manager from r81.10 to r81.20.

Cpuse doesn't list r81.20 though. I can see different  r81.10 hot fixes but I can see any r81.20 package. Why would it happen? 
I have another firewall manager vm in the lab running r81.10 and I can see the list of r81.20 packages in cpuse.

[Alex-]

This happens if your partitioning isn't compatible or similar.

You will need an advanced upgrade with migrate_server on a new server.

[Luis_Miguel_Mig]

I have read that partition or disk requirements could cause the installation to fail but not the prevent r81.20 to be shown as an option.

Is there anyway to troubleshoot it or some sort of  cpuse verbose logs?

[Alex-]

You can import the R81.20 image manually in CPUSE and run the verifier to see if you get more information.

Given the advantages of installing on a new system, I wouldn't go through the trouble and perform an advanced upgrade instead.

[Luis_Miguel_Mig]

you are right Alex. I imported r81.20 manually and I got that error because we have two  raid logic disks on for the system and one for the logs.

So I guess I have no option but going through the pain of setting up a new management pair of servers. 

Such a pity because ì am quite happy with the current open server managers.

Any workaround, alternative or suggestion?

[the_rock]

Can you share the error?

Andy

[Luis_Miguel_Mig]

error attached

[the_rock]

Can you send output of below?

df -h

parted -l

[Luis_Miguel_Mig]

attached

[the_rock]

I see its totally different, so as @Alex- said, this probably wont work as far as upgrade. Maybe TAC can give some sort of workaround, not sure.

Below is what it should look like.

Andy

[Expert@CP-FW-01:0]# parted -l
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vg_splat-lv_current: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0.00B 21.5GB 21.5GB xfs

Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vg_splat-lv_log: 46.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0.00B 46.2GB 46.2GB xfs

Model: Virtio Block Device (virtblk)
Disk /dev/vda: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 317MB 315MB ext3
3 317MB 8907MB 8590MB linux-swap(v1)
4 8907MB 107GB 98.5GB lvm

[Expert@CP-FW-01:0]#

[Luis_Miguel_Mig]

totally different? Not really ,just two disks instead of one.
Is there anything else I am missing? 

I was wondering if I can take advantage of the Management HA so I don't need to be worried about migrate export.

So I could do a fresh install in the secondary management with one disk, sync it and failover and repeat the process with the management primary with one disc and sync

I guess management HA is not concerned about the disk partitions, right?

[the_rock]

Partition table is different, not sure if that could be one of the reasons. Yea, mgmt HA may be good option here.

Andy

[PhoneBoy]

Given the fdisk and installer improvements, you might find performance improves dramatically by doing a clean install and advanced migration.

[Luis_Miguel_Mig]

so clean install and sync on the secondary

and clean install and advanced migration on the primary

If I do clean install and advance migration from r81.10 to r81.20 just to get installed r81.10  in one disk, I guess I won't need to get worried about SIC licenses etc. And then I can upgrade to r81.20.

Or would you do clean install and advanced migration from r81.10 to r81.20? If I do that on the same server, I guess SIC will be okay,  licenses will be okay straight away. So it may be cleaner but it feels a bit riskier, doesn't it?

[PhoneBoy]

When doing any sort of upgrade involving Management HA, the secondary node has to be done as a clean install.
In this case, your primary management also needs a clean install (to get the aforementioned benefits).

You might be able to reinstall the secondary node with R81.20, downgrade to R81.10 (use the Clean Install option in CPUSE), and reconfigure Management HA.
Then promote to primary and do the same on the other node.

No idea if that will work, of course.
I'd still suggest taking a backup with migrate_server before proceeding with any of this.

[Luis_Miguel_Mig]

If I do r81.20 fresh install on the primary first and import the configuration, what will it happen in that situation when the primary is running r81.20 and the secodary/active is running r81.10?
Does HA support managers running two different versions? Or should I disconnect the secondary/active running r81.10  first?

[PhoneBoy]

Management HA requires the same version/JHF level on both nodes.
When you upgrade the Primary (by whatever process), you will have to clean install the Secondary and reconfigure Management HA.

[Luis_Miguel_Mig]

Absolutely, but I mean just before clean install the secondary, there is a moment where both managers are running different versions. Do you mean that in that scenario they both believe they are active but they can't speak with each other and  none of them will be able to sync with each other?

[the_rock]

This is really bugging me now, I may test it in the lab again. I could bet in any money that when I did this in the past, I did NOT have same jumbo installed on both and sync worked fine. Since I got couple of hours, I will do it now and report back the results.

Andy

[Luis_Miguel_Mig]

the thing is that after upgrading the primary to r81.20 and migrating the database I may want to wait and leave the secondary in r81.10 for one day so  we can test the primary in r81.20 and still have and easy rollback plan  with the secondary running r81.10 

but I want to know exactly what to expect just to make sure I don't break anything with those managers running one r81.10 and the other r81.20 for one day.
I guess in case of doubts I can just disconnect the secondary running r81.10 for one day.

[the_rock]

Give me 1 more hour, I will test jumbo hotfix theory.

Andy

[Bob_Zimmerman]

A management server only becomes active when you log in to it and tell it to become active. Unless you go out of your way to cause this scenario, they won't both believe they're active at the same time.

Just make sure they're synchronized, upgrade your primary, rebuild your secondary, and synchronize them.

[Luis_Miguel_Mig]

Well after upgrading the primary to r81.20 I will login I will make it active to test it  before I do the secondary. And obviously I will upgrade the secondary if the testing the primary on r81.20 is succesful.
So my concern is what will it happen with the secondary in that intermediate moment. 
If both can't be active at the same time that means that they are able to interoperate with each other, and when I make the primary r81.20 active it will automatically make the secondary r81.10 not active.
 
That is what I would like to know beforehand

[the_rock]

Just tested the jumbo hotfix theory, makes no difference. I have jumbo 70 on one member, nothing on the other, its R81.20, they sync just fine. I even made secondary one active, no issues

Andy

[Luis_Miguel_Mig]

yeah it can make sense for same version and different jumbos but I guess it may be a different story if one manager runs r81.10 and the other r81.20

[the_rock]

That will never sync, because its totally different versions. Its sort of same thing if you are talking about clusterXL, if say one gets upgraded and other one is on lower version.

Andy

[Luis_Miguel_Mig]

Thanks that is what I wanted to hear. 

If it works like clusterxl is great, safe and predictable. The new version stays DOWN and the old version ACTIVE. So it means that ì need to disconnect the secondary running r81.10 if I want to test the primary running r81.20.

[the_rock]

EXACTLY!

[Luis_Miguel_Mig]

Thanks.
By the way, with clusterXL MVC (multi version cluster) upgrade they can sync and be active/standby with different versions, right?
I have to test it soon 😉

[the_rock]

Right...BUT, as @emmap was saying in one post recently, that method is there to enable HIGHER version to sync with lower version member, so you ONLY enable it on backup member, which is the first one you will upgrade anyway.

See below.

Andy

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Installation_and_Upgrade_Guide/Top...