FYI: These steps can also be used when upgrading any major Filr release (like Filr 2 to Filr 3, any upgrade requiring an appliance replacement, preserving the vastorage disk).

Additional Disclaimer: This is an untested by engineering and therefor unsupported procedure, so if the end-result is unexpected, use the documented and supported manner instead.

Although it is strongly recommended to remove the snapshots, as documented, several admins prefer to be save and want to have a snapshot (or several snapshots) before performing an upgrade or updated.

Even though you basically preserve the old VMs when upgrading to Filr 4, some are somewhat reluctant to remove their snapshots, or have a back-up solution based on snapshots.

On VMware ESX and ESXi you can circumvent this by using the command line interface (CLI) tools of the hypervisor and clone the disk in stead of copying it.
(Cloning the virtual disk (.vmdk) basically creates a new disk but with the contents of an existing .vmdk)

This is the only step that differs from the normal upgrade procedure as documented.

This would be the procedure to achieve this, if required:

1. 1. Enable ssh access to the ESX or ESXi node(s)

1. 1. Make sure that the Filr 3 environment is running 3.4.3 or later.

1. 1. In case of a small (all-in-one) deployment, make sure that the vastorage is large enough to hold the dump of the mysql database.

1. 1. Install the "Pre-Upgrade Scripts for Filr ALL IN ONE Deployment" patch.
      
      (https://download.novell.com/Download?buildid=zHKfRQcM9RA~)

1. 1. Obtain the required OVFs for Filr 4 (or later).

1. 1. Deploy the same amount of appliance types as currently running.
      (ie. 3 Filr, 2 Lucene and a Database appliance or in case of a small (all-in-one) just the Filr appliance)

1. 1. Determine the current virtual disk used by the Filr 3 VM(s) for vastorage and note it down for each node (but the Database node, later on that).
      
      (ie Filr-3-NODE01-VASTORAGE-00002.vmdk)

1. 1. In case of a small (all-in-one) filr setup, stop the filr service and execute sh /opt/novell/filr_upgrade/pre-upgrade.sh (as per the documentation).

1. 1. Power off the Filr 3 infrastructure (but the database appliance in case of a large or expandable setup).

1. 1. Access the ESX or ESXi nodes over ssh.

1. 1. cd into the directory of the first VM you need to upgrade
      
      (ie. cd /vmfs/volumes/datastore1/Filr-3-NODE01/)

1. 1. Clone, using vmkfstools, the current disk used by the Filr 3 VM into the folder of the deployed Filr 4 appliance that will be used for it's upgrade.
      Depending on it's size, this can take a while.
      
      (ie. vmkfstools -i ./Filr-3-NODE1-VASTORAGE-00002.vmdk /vmfs/volumes/datastore2/Filr4-NODE01/Filr-4-NODE01-VASTORAGE.vmdk -d eagerzeroedthick)
      
      
      1. !Optional, but usefull! generate a new empty disk for /var using a name that makes sense to humans
         
         (ie. vmkfstools -c 100g -d eagerzeroedthick /vmfs/volumes/datastore2/Filr-4-NODE01/Filr-4-NODE01-VAR.vmdk )

1. 1. Repeat the previous step for all Filr related appliances (except the MySQL one).

1. 1. Power on the PostgreSQL appliance (or server) and configure as per the documentation.

1. Configure the Filr (and Lucene) appliance(s):
   
   
   1. Add 2 additional SCSI controllers
   2. Add the existing disk you cloned as SCSI1:0 (second controller, first disk)*
   3. Add either a new disk for /var (or the one from step 12a as an existing one) as SCSI20: (third scsi controller, first disk)*
   4. In case the Filr 3 appliance had more RAM assigned, increase the assigned RAM**
      
      (otherwise leave the preset value as these are the new minimum values)

These were the steps that differ from the normally documented upgrade procedure.

After this you can power on the appliances and perform the upgrade as per the regular documentation.

The main reason that the MySQL appliance is not upgraded in a large or expandable setup, but a new PostgreSQL appliance is deployed (with a different DNS name and IP) is that, as documented, after the upgrade of the Filr and Lucene appliance(s) and the post-upgrade tasks, the database is basically migrated over the wire by a Filr appliance from the MySQL appliance (or server) towards the PostgreSQL appliance (or server).

For performance reasons (and fault tolerance) it is still a recommendation to build a database environment on bare metal.

In VMWare, for performance reasons, it's recommended not to use "thin" disks, though in a LAB or TEST environment, where disk space is limited, it can be used.

* Adding the additional SCSI controllers and making sure that the system disk is SCSI0:0 VASTORAGE is SCSI1:0 and VAR is SCSI2:0 insures that the Linux OS uses the correct disk sequence / hierarchy. This means that trough out the life of the VM / is /dev/sda1, /vastorage is /dev/sdb1 and /var is /dev/sdc1 (even when they are added in a different sequence in the VM).

** for Filr 4, due to the new underlaying architecture, at the time of this writing, it's recommended to:

• • Set the JVM MIN and MAX of the Filr appliance to ~60% of the assigned RAM.
    
    It is recommended to either increase the assigned RAM so the JVM set in Filr 3 is ~60% of the new appliance's RAM.
    
    After the upgrade, if the Filr 3 ie had 8GB, it's recommended to increase the JVM to ~60% of the RAM (ie. 9GB if the VM has the default 16GB RAM)

• The recommendations for the Lucene appliance remain roughly the same as for Filr 3.
  
  The JVM MIN value set to ~33% and the JVM MAX value set to ~50%