If the disks disappear when setting up a new Panorama, you can re-add them with

request system raid add A1

If the box is new hardware, you may have to run the command on all the disks to get them working properly.

show system raid detail

The simple way to size the amount of storage you need on a panorama box is

LPS = Logs Per Second

<pre>( ( (LPS * 86400) * days ) * logsize ) / 1000000000 = Log Storage in GB</pre>

More details here.

Scenario, you have a PAN firewall (e.g. a PA-5050) and you want to upgrade to another model (e.g. a PA-5220).

If you manage the firewall with Panorama (even if it is just Device Groups), you will find a chicken/egg situation where you cannot change the interfaces without updating the policies (NAT/PBF) and vice versa. Since you can't update both at the same time (the joys of Panorama), you become stuck.

The solution that follows assums the new firewalls have been added to Panorama and are members of the same device group as the old firewall. It also assums the device group has already been pushed to both the old firewall and the new firewall. We also assume that the new firewall is not live yet as it will experience downtime during this process (the original one shouldn't though).

Start off by identifying all the Device Group policy rules that refer to the interfaces.

Clone these rule. In othe original rule, use the “Target” feature to aim the rule at the old firewall. Use the “Target” feature to aim the clone rule at the new firewall.

Commit to panorama and push out to the devices. There should be no difference.

Now disable the policy rules that refer to the interfaces and point to the new firewall. Commit these rules to the new firewall. It has the effect of removing the rules from the firewall.

Now update the interfaces, virtual routers, DNS relay, DHCP servers/relay, QOS, VPN, GlobalProtect, etc and commit to the new firewalls.

Once done, updated the disabled rules in Panorama that point to the new firewall to use the new interfaces. Enable the ruels and commit.

The “Export Config” feature on Panorama can only SCP to a Linux SCP server - not a Windows SCP server.

The IP address assigned to the management port needs to be routable and there is communication between the HA peers. The HA connection uses TCP port 28 with encryption enabled and 28769 when encryption is not enabled.

More detail information can be retrieved via the Command Line interface including view the RAID drive status. From an ssh connection, enter the operational command:

show system raid detail

Displays information about log forwarding for each managed device:

show log-collector serial-number 0000000000

When replacing a failed disk, do not format the new disk. Because the drive is installed into a RAID array, the RAID process will begin to mirror the existing data onto the new disk. Using the CLI, enable the disk pair on Log Collector by issuing the command for the disk pair replaced.

request system raid add <log-disk-pair> force no-format

Operation may take few minutes. To check status issue the following operational command for status

show system raid detail

Note: When moving drives to a new RMA'ed M-Series, it is important to use “force” with “no-format” option. Force option lets you associate the disk pair that is previously associated with another Log Collector. The option “no-format” keeps the logs by not formatting the disk drives.

When dividing the Logging, in the primary panorama, create the managed collectors. then go to collector groups.

Add both panoramas to “Collector Group Member”

In “Log forwarding preferences”, create on row with the primary site firewalls and the primary panorama.

create a second row with the secondary site firewalls and the secondary panorama This document shows how to upgrade Panorama VM running PAN-OS 7.1.10 to PAN-OS 8.0.2.

If you deployed Panorama using the PANOS 8.0 OVA file, you will most likely just have to increment the CPU count (or number of cores) to 8 and RAM size to 16GB and then run the following command

request system system-mode panorama

You will also have to add a secondary disk for logging that is at least 50GB.

It is assumed that the Panorama VM has its original system disk and has already had a second disk added for logging. In this example, the logging disk is 100GB and has had logs written to it.

Palo resources are here.

Step 1) Upgrade the Panorama VM from 7.1.10 to 8.0.2. Do not reboot the VM when the software prompts you.

Step 2) Shutdown the Panorama VM. Incremend the CPU count (or number of cores) to 8 and RAM size to 16GB.

Step 3) Add a new disk that is exactly 81 GB in VMware ESXi. It is strongly recommended to make this disk thick provisioned. However, for my testing I used thin provisioning.

Step 4) Boot the Panorama VM and make sure all is well. You should see in the Web GUI that Panorama is now running PAN-OS 8.0.2 and is in 'Legacy' mode.

Step 5) Use show system disk details command to show disks. Status = Available means that the disk is in use (E.g. the current logging disk). If Status = Unavailable, it means that the disk is not being used and is (ironically) available for our use.

Step 6) Use the request system clone-system-disk target sdc command to clone the system disk to the new, larger disk. Change sdc as appropriate. Choose the disk that has a size of 82944 MB. This is 81GB in size. If all the pre-requisits are met, PAN-OS will then reboot the appliance and start copying data. This may take at least 10 minutes.

Step 7) When the data copy is complete, you will have to manually power off the Panorama VM as you won't get a command prompt to do so.

Step 8) At this point, with the Panorama VM still powered off, remove (but do not delete) the original system disk. Then edit the new disk to use SCSI channel 0:0 instead of 0:2 (if applicable).

Step 9) Boot the Panorama VM and make sure all is well. Log into the Web GUI and make sure everything seems in order.

Step 10) As we have a seperate logging disk, we need to add a secondary logging disk to the Panorama VM before we can migrate from Legacy mode to Panorama mode. Power off the system and add a secondary logging disk that is the same size as the current logging disk.

Step 11) Boot the Panorama VM and make sure all is well. Log into the Web GUI and make sure everything seems in order.

Step 12) Run the following command to migrate from Legacy mode to Panorama mode request system system-mode panorama. This will restart the Panorama VM.

Step 13) When the Panorama VM has rebooted, log into the Web GUI and make sure everything seems in order.

Step 14) You now see logs in Panorama that were generated since the move from Legacy to Panorama mode. However, older logs are no longer visible. To access them, we need to migrate them with the following command request logdb migrate vm start. This can take a very long time (days) if you have a huge number of logs. You can monitor progress of the migration with the following command request logdb migrate vm status. You can pause the progress of the migration with the following command request logdb migrate vm stop.

Step 15) When the migration is complete, power off the Panorama VM and remove (but do not delete… yet) the old logging disk. This should leave you with just one system disk and one logging disk.

Step 16) Boot the Panorama VM and make sure all is well. Log into the Web GUI and make sure everything seems in order.

Note: Don't forget that you may need to create a collector and name the Panorama appliance as the collector. You then create a collector group with the Panorama as the only member. You then need to commit to Panorama and then push out to the device collector (which is effecticly pushing to itself).

The following log summary took a few minutes to achive

admin@palo-panorama> request logdb migrate vm status

migration has been done

'traffic' is done. 325731 records migrated.
'config' is done. 12015 records migrated.
'system' is done. 23039 records migrated.
'threat' is done. 10221 records migrated.
'appstat' is done. 0 records migrated.
'event' is done. 0 records migrated.
'alarm' is done. 0 records migrated.
'hipmatch' is done. 0 records migrated.
'userid' is done. 0 records migrated.
'iptag' is done. 0 records migrated.
'mdm' is done. 0 records migrated.
'extpcap' is done. 0 records migrated.
'gtp' is done. 0 records migrated.
'auth' is done. 0 records migrated.