Menu Close
Red Hat Training
A Red Hat training course is available for Red Hat CloudForms
Migrating to Red Hat CloudForms 4.7
Upgrading your system from earlier versions of Red Hat CloudForms Management Engine
Red Hat CloudForms Documentation Team
cloudforms-docs@redhat.com
Abstract
Preface
This document describes the process of migrating an older Red Hat CloudForms environment to Red Hat CloudForms 4.7 (CFME 5.10). Chapter 8, Updating CloudForms also provides instructions for applying minor updates (errata) to your CloudForms appliances.
You can migrate directly to Red Hat CloudForms 4.7 (CFME 5.10) from the following versions:
- Red Hat CloudForms 4.6 (CFME 5.9)
- Red Hat CloudForms 4.5 (CFME 5.8)
- Red Hat CloudForms 4.2 (CFME 5.7)
- Red Hat CloudForms 4.1 (CFME 5.6)
- Red Hat CloudForms 4.0 (CFME 5.5)
- See Migrating to Red Hat CloudForms 4.5 for documentation on migrating version 4.1 or version 4.2 to version 4.5.
- See Migrating and Updating Red Hat CloudForms / Red Hat CloudForms Management Engine for articles on migrating to CloudForms versions prior to 4.5.
Chapter 1. Ordering Migrations
Migrate all remote regions before migrating the global region. This requirement ensures prevention of missed schema states and instances of inability to replicate changes from a remote region.
Recovering from Migration Errors
Migration error messages will appear when bin/rake db:migrate
is executed on the global region before migrating remote regions.
Example Error Message:
Waiting for remote region X to run migration 2012154125454
Press Ctrl-C
from the command line to interrupt the application.
Do not run evmserverd
if a database is in a partially migrated state.
Chapter 2. Modifying the Postgresql Configuration
This procedure modifies the strategy used for making changes to the PostgreSQL configuration. Previously, changes were made directly to the postgresql.conf
file in the data directory. After switching to the new configuration, changes will be made by editing a separate file in the /etc/manageiq/postgresql.conf.d
directory. This modification allows future PostgreSQL configuration changes to be made more easily.
The 01_miq_overrides.conf
file in the /etc/manageiq/postgresql.conf.d
directory is reserved for application overrides and will be recreated on application updates; this file should not be edited. Additional files will be read by the PostgreSQL server process according to the documentation here: https://www.postgresql.org/docs/9.5/config-setting.html#CONFIG-INCLUDES.
Back up the
postgresql.conf
file so that you have any configuration changes:# cp $APPLIANCE_PG_DATA/postgresql.conf <file_location>
Copy the updated
postgresql.conf
file to thepg_data
directory:# cp $APPLIANCE_SOURCE_DIRECTORY/TEMPLATE/var/opt/rh/rh-postgresql95/lib/pgsql/data/postgresql.conf $APPLIANCE_PG_DATA/postgresql.conf
Optional: If you have made changes to the
postgresql.conf
file prior to following this procedure, create a new02_user_overrides.conf
file, and add any modifications you have from the originalpostgresql.conf
file. Example layout of the02_user_overrides.conf
file:#---------------------------------------------- # WRITE AHEAD LOG #---------------------------------------------- wal_level = 'logical' wal_log_hints = on wal_buffers = 16MB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.9
Once the
02_user_overrides.conf
file has been modified and saved, restart thepostgresql
service:# systemctl restart $APPLIANCE_PG_SERVICE
All postgresql.conf
customizations will now be made to files in the /etc/manageiq/postgresql.conf.d
directory due to the following include_dir
line in the default configuration. The settings in these new files will override ones in the postgresql.conf
file.
include_dir = '/etc/manageiq/postgresql.conf.d`
Chapter 3. Migrating from CloudForms 4.6 (CFME 5.9) to CloudForms 4.7 (CFME 5.10)
3.1. Overview
This procedure describes the process of migrating Red Hat CloudForms 4.6 (CFME 5.9) to Red Hat CloudForms 4.7 (CFME 5.10). This procedure does not necessarily include migration of all possible customer modifications, so it is recommended that you fully test any modifications before migrating your environment.
- Read through all of the steps in this procedure before beginning the migration process.
- CloudForms 4.7 appliances require 12 GB memory which is the same as the previous version. However, before migrating your appliances, adjust resources in your environment to avoid performance issues. See Migration Considerations in the Release Notes for more information.
- CloudForms 4.6 high availability environments require additional configuration. See Additional Configuration in High Availability Environments.
You can classify the migration into three groups of appliances:
- VMDB appliance - An appliance with workers running, which also hosts its own database that other appliances can also connect to.
- Non-VMDB appliance - An appliance with workers running which does not host a database. The appliance is connected to an external database.
- Dedicated database appliance - A CloudForms appliance or non-CloudForms virtual machine with no workers running on it: the appliance contains only a database for other appliances to connect to.
Migration Workflow Summary
In summary, the migration process from CFME 5.9 to CFME 5.10 follows this workflow:
Appliances must be offline during migration; ensure you plan for downtime when migrating.
- Back up appliances (optional but recommended).
Prepare appliances:
- Disable older CloudForms repositories and enable new repositories.
- Resize the disk space on the virtual machines hosting the appliances.
-
Shut down
evmserver
on the master or global appliance.
Migrate appliances:
- Update CFME packages on all appliances.
- Load the new version of the pglogical library on the VMDB and dedicated database appliances.
- Migrate the non-VMDB and VMDB appliance databases and update the Automate Model.
- Restart PostgreSQL on the VMDB and dedicated database appliances.
-
Restart
evmserver
on the VMDB and non-VMDB appliances.
- Configure replication after the migration process is complete and appliances are running once again.
3.2. Backing Up Current Appliances
These steps will not affect the operations of your CloudForms infrastructure. However, they will help ensure that you are able to roll back if required and replicate the network settings.
- Back up the databases of your CFME 5.9 appliances. Take a snapshot if possible.
Back up the following files for disaster recovery, noting which appliance each comes from:
-
/var/www/miq/vmdb/GUID
-
/var/www/miq/vmdb/REGION
-
During the upgrade, the iptables configuration file (
/etc/sysconfig/iptables
) is removed. If you have changed the iptables configuration from the default (runiptables --list -n
to see the current configuration), use the following command to back up the iptables configuration:# iptables-save > /etc/iptables.conf
You can restore your iptables configuration file with the following command:
# iptables-restore < /etc/iptables.conf
Alternatively, add this command to
/etc/rc.local
to reload the rules at every reboot.
For 5.9 appliances with the User Interface server role: Before migration, ensure that the Web Services role is enabled (it is enabled by default in CFME 5.9). If the Web Services role is disabled, it will not be turned on during the migration process. This role is required in CFME 5.10 to log in to the user interface.
3.3. Preparing the Appliances for Migration
On all appliances:
Disable the CloudForms 4.6 (CFME 5.9) repositories:
# subscription-manager repos --disable=cf-me-5.9-for-rhel-7-rpms
NoteSee Enabling Supplementary and Optional Repositories in Using and Configuring Red Hat Subscription Manager for more information.
Enable the CloudForms 4.7 (CFME 5.10) repositories:
# subscription-manager repos --enable=rhel-7-server-rpms \ --enable=cf-me-5.10-for-rhel-7-rpms \ --enable=rhel-7-server-extras-rpms \ --enable=rhel-7-server-ansible-2.7-rpms \ --enable=rhel-7-server-rh-common-rpms \ --enable=rhel-server-rhscl-7-rpms
3.4. Resizing the Disk Space
This section only applies for customers upgrading from CFME 5.9.0.17 versions. Customers upgrading from the latest CFME 5.9 versions already have the partition changes and need not follow this procedure.
CloudForms 4.6 and newer require more disk space than previous CloudForms versions because of the addition of built-in Ansible features. Before migrating your appliances to CloudForms 4.7, resize the virtual machine partition hosting the appliances to ensure sufficient space is available for the appliance.
Complete the following steps to resize the disk space, replacing filenames as needed:
Install the
xfsdump
tool for backing up filesystems:# yum -y install xfsdump
Back up the partition’s existing filesystem,
/repo
, to a temporary repository,/tmp/repo
:# xfsdump -F -f /tmp/repo /repo
Unmount the existing filesystem:
# umount /repo
Remove the logical volume:
# lvremove -f /dev/VG-CFME/lv_repo
Create a new 1GB logical volume in the existing volume group
lv_repo
:# lvcreate --yes -L 1GB -n lv_repo VG-CFME
Construct the volume path:
# mkfs.xfs /dev/VG-CFME/lv_repo
Mount the volume to
/repo
:# mount /dev/VG-CFME/lv_repo /repo
Restore the
/tmp/repo
filesystem data to the old filesystem:# xfsrestore -f /tmp/repo /repo
Resize the volume to allow sufficient space for the CloudForms 4.7 appliance:
# lvextend --resizefs --size +9GB /dev/VG-CFME/lv_var
3.5. Migrating from CFME 5.9 to 5.10
Perform the following steps on your CloudForms VMDB, non-VMDB and dedicated database appliances to migrate to CFME 5.10. Migrate all remote regions before migrating the global region. See Chapter 1, Ordering Migrations for more information.
Some steps are run on certain appliances. Ensure you wait for each command to finish before going to the next step.
- Connect to the appliance using SSH.
On the VMDB and non-VMDB appliances, stop the
evmserver
process:[root@VMDB]# systemctl stop evmserverd [root@non-VMDB]# systemctl stop evmserverd
Update packages on all appliances:
[root@VMDB]# yum update [root@non-VMDB]# yum update [root@dedicatedDB]# yum update
On the VMDB and dedicated database appliances, restart the server to load the new version of the
pglogical
library:[root@VMDB]# systemctl restart $APPLIANCE_PG_SERVICE [root@dedicatedDB]# systemctl restart $APPLIANCE_PG_SERVICE
On the VMDB and non-VMDB appliances, log out of the appliance, then log back in to fully reload Ruby.
ImportantFailure to log out of the old shell environment and back into a new one results in an error reporting a Ruby gem is missing.
If you did not log out and log back in and received the error message about the missing gem, you can re-login and continue with the next step. But if you ran
bundle install
after the error, you must runyum reinstall cfme-gemset
to fix the broken environment in order to continue.On the VMDB and non-VMDB appliances, change to the
vmdb
directory:[root@VMDB]# cd /var/www/miq/vmdb/ [root@non-VMDB]# cd /var/www/miq/vmdb/
On the VMDB and non-VMDB appliances, run the below command appropriate to your environment to migrate everything in the database to work with the latest 5.10 configuration:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake db:migrate
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake db:migrate
On the VMDB and non-VMDB appliances, update the Automate Model to the latest version. This resets the ManageIQ and Red Hat domains (base domains) to a new and upgraded version. Run the command appropriate to your environment to update the Automate Model:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake evm:automate:reset
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake evm:automate:reset
On the VMDB and dedicated database appliances, restart PostgreSQL:
[root@VMDB]# systemctl restart rh-postgresql95-postgresql [root@dedicatedDB]# systemctl restart rh-postgresql95-postgresql
On the VMDB and non-VMDB appliances, start the
evmserver
process:In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# systemctl start evmserverd
In a dedicated database or highly available environment, run this command on each non-VMDB appliance:
[root@non-VMDB]# systemctl start evmserverd
3.6. Additional Configuration for High Availability Environments
Red Hat CloudForms 4.6 high availability environments require additional configuration after upgrading to CloudForms 4.7.
Run the following commands on all VMDB and dedicated database appliances:
Update packages:
# yum update
Reload the
systemd
manager configuration:# systemctl daemon-reload
Stop the
repmgrd
daemon. This prevents unwanted failovers and ensuresrepmgrd
will start properly after the upgrade:# systemctl stop rh-postgresql95-repmgr
Restart
postgresql
:# systemctl restart $APPLIANCE_PG_SERVICE
Verify that
shared_preload_libraries
listsrepmgr
:# psql -d vmdb_production -c 'show shared_preload_libraries'
NoteIf
repmgr_funcs
shows inshared_preload_libraries
manually change the value in thepostgresql
configuration file.
On the primary database-only appliance(node):
Edit
/etc/repmgr.conf
to:node_id=<id> node_name=<hostname> conninfo='host=<hostname> user=root dbname=vmdb_production' use_replication_slots=1 pg_basebackup_options='--xlog-method=stream' failover=automatic promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file' follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n' log_file=/var/log/repmgr/repmgrd.log service_start_command='sudo systemctl start rh-postgresql95-postgresql' service_stop_command='sudo systemctl stop rh-postgresql95-postgresql' service_restart_command='sudo systemctl restart rh-postgresql95-postgresql' service_reload_command='sudo systemctl reload rh-postgresql95-postgresql' data_directory='/var/opt/rh/rh-postgresql95/lib/pgsql/data'
Execute the command string
'CREATE EXTENSION repmgr FROM unpackaged'
:# psql -d vmdb_production -c 'CREATE EXTENSION repmgr FROM unpackaged'
Initialize
repmgr
installation and register the primary node:# su -c 'repmgr primary register -f /etc/repmgr.conf --force' - postgres
On the standby database nodes:
Edit
/etc/repmgr.conf
to:node_id=<id> node_name=<hostname> conninfo='host=<hostname> user=root dbname=vmdb_production' use_replication_slots=1 pg_basebackup_options='--xlog-method=stream' failover=automatic promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file' follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n' log_file=/var/log/repmgr/repmgrd.log service_start_command='sudo systemctl start rh-postgresql95-postgresql' service_stop_command='sudo systemctl stop rh-postgresql95-postgresql' service_restart_command='sudo systemctl restart rh-postgresql95-postgresql' service_reload_command='sudo systemctl reload rh-postgresql95-postgresql' data_directory='/var/opt/rh/rh-postgresql95/lib/pgsql/data'
Initialize
repmgr
installation and register the standby node:# su -c 'repmgr standby register -f /etc/repmgr.conf --force' - postgres
Start
repmgrd
:# systemctl start rh-postgresql95-repmgr
On all CloudForms appliances:
Restart the
evm-failover-monitor
:# systemctl restart evm-failover-monitor
Chapter 4. Migrating from CloudForms 4.5 (CFME 5.8) to CloudForms 4.7 (CFME 5.10)
4.1. Overview
This procedure describes the process of migrating Red Hat CloudForms 4.5 (CFME 5.8) to Red Hat CloudForms 4.7 (CFME 5.10). This procedure does not necessarily include migration of all possible customer modifications, so it is recommended that you fully test any modifications before migrating your environment.
- Read through all of the steps in this procedure before beginning the migration process.
- CloudForms 4.7 appliances require 12 GB memory which is the same as the previous version. However, before migrating your appliances, adjust resources in your environment to avoid performance issues. See Migration Considerations in the Release Notes for more information.
You can classify the migration into three groups of appliances:
- VMDB appliance - An appliance with workers running, which also hosts its own database that other appliances can also connect to.
- Non-VMDB appliance - An appliance with workers running which does not host a database. The appliance is connected to an external database.
- Dedicated database appliance - A CloudForms appliance or non-CloudForms virtual machine with no workers running on it: the appliance contains only a database for other appliances to connect to.
Migration Workflow Summary
In summary, the migration process from CFME 5.8 to CFME 5.10 follows this workflow:
Appliances must be offline during migration; ensure you plan for downtime when migrating.
- Back up appliances (optional but recommended).
Prepare appliances:
- Disable older CloudForms repositories and enable new repositories.
- Resize the disk space on the virtual machines hosting the appliances.
-
Shut down
evmserver
on the master or global appliance.
Migrate appliances:
- Update CFME packages on all appliances.
- Load the new version of the pglogical library on the VMDB and dedicated database appliances.
- Migrate the non-VMDB and VMDB appliance databases and update the Automate Model.
- Restart PostgreSQL on the VMDB and dedicated database appliances.
-
Restart
evmserver
on the VMDB and non-VMDB appliances.
- Configure replication after the migration process is complete and appliances are running once again.
4.2. Backing Up Current Appliances
These steps will not affect the operations of your CloudForms infrastructure. However, they will help ensure that you are able to roll back if required and replicate the network settings.
- Back up the databases of your CFME 5.8 appliances. Take a snapshot if possible.
Back up the following files for disaster recovery, noting which appliance each comes from:
-
/var/www/miq/vmdb/GUID
-
/var/www/miq/vmdb/REGION
-
During the upgrade, the iptables configuration file (
/etc/sysconfig/iptables
) is removed. If you have changed the iptables configuration from the default (runiptables --list -n
to see the current configuration), use the following command to back up the iptables configuration:# iptables-save > /etc/iptables.conf
You can restore your iptables configuration file with the following command:
# iptables-restore < /etc/iptables.conf
Alternatively, add this command to
/etc/rc.local
to reload the rules at every reboot.
For 5.8 appliances with the User Interface server role: Before migration, ensure that the Web Services role is enabled (it is enabled by default in CFME 5.8). If the Web Services role is disabled, it will not be turned on during the migration process. This role is required in CFME 5.10 to log in to the user interface.
4.3. Preparing the Appliances for Migration
On all appliances:
Disable the CloudForms 4.5 (CFME 5.8) repositories:
# subscription-manager repos --disable=cf-me-5.8-for-rhel-7-rpms
NoteSee Enabling Supplementary and Optional Repositories in Using and Configuring Red Hat Subscription Manager for more information.
Enable the CloudForms 4.7 (CFME 5.10) repositories:
# subscription-manager repos --enable=rhel-7-server-rpms \ --enable=cf-me-5.10-for-rhel-7-rpms \ --enable=rhel-7-server-extras-rpms \ --enable=rhel-7-server-ansible-2.7-rpms \ --enable=rhel-7-server-rh-common-rpms \ --enable=rhel-server-rhscl-7-rpms
4.4. Resizing the Disk Space
This section only applies for customers upgrading from CFME 5.8.0.17 versions. Customers upgrading from the latest CFME 5.8 versions already have the partition changes and need not follow this procedure.
CloudForms 4.5 and newer require more disk space than previous CloudForms versions because of the addition of built-in Ansible features. Before migrating your appliances to CloudForms 4.7, resize the virtual machine partition hosting the appliances to ensure sufficient space is available for the appliance.
Complete the following steps to resize the disk space, replacing filenames as needed:
Install the
xfsdump
tool for backing up filesystems:# yum -y install xfsdump
Back up the partition’s existing filesystem,
/repo
, to a temporary repository,/tmp/repo
:# xfsdump -F -f /tmp/repo /repo
Unmount the existing filesystem:
# umount /repo
Remove the logical volume:
# lvremove -f /dev/VG-CFME/lv_repo
Create a new 1GB logical volume in the existing volume group
lv_repo
:# lvcreate --yes -L 1GB -n lv_repo VG-CFME
Construct the volume path:
# mkfs.xfs /dev/VG-CFME/lv_repo
Mount the volume to
/repo
:# mount /dev/VG-CFME/lv_repo /repo
Restore the
/tmp/repo
filesystem data to the old filesystem:# xfsrestore -f /tmp/repo /repo
Resize the volume to allow sufficient space for the CloudForms 4.7 appliance:
# lvextend --resizefs --size +9GB /dev/VG-CFME/lv_var
4.5. Migrating from CFME 5.8 to 5.10
Perform the following steps on your CloudForms VMDB, non-VMDB and dedicated database appliances to migrate to CFME 5.10. Migrate all remote regions before migrating the global region. See Chapter 1, Ordering Migrations for more information.
Some steps are run on certain appliances. Ensure you wait for each command to finish before going to the next step.
- Connect to the appliance using SSH.
On the VMDB and non-VMDB appliances, stop the
evmserver
process:[root@VMDB]# systemctl stop evmserverd [root@non-VMDB]# systemctl stop evmserverd
Update packages on all appliances:
[root@VMDB]# yum update [root@non-VMDB]# yum update [root@dedicatedDB]# yum update
On the VMDB and dedicated database appliances, restart the server to load the new version of the
pglogical
library:[root@VMDB]# systemctl restart $APPLIANCE_PG_SERVICE [root@dedicatedDB]# systemctl restart $APPLIANCE_PG_SERVICE
On the VMDB and non-VMDB appliances, log out of the appliance, then log back in to fully reload Ruby.
ImportantFailure to log out of the old shell environment and back into a new one results in an error reporting a Ruby gem is missing.
If you forgot to log out and log back in and got the error message about missing gem, you can relogin and continue with the next step. But if you ran
bundle install
after the error, you must runyum reinstall cfme-gemset
to fix the broken environment.On the VMDB and non-VMDB appliances, change to the
vmdb
directory:[root@VMDB]# cd /var/www/miq/vmdb/ [root@non-VMDB]# cd /var/www/miq/vmdb/
On the VMDB and non-VMDB appliances, run the below command appropriate to your environment to migrate everything in the database to work with the latest 5.10 configuration:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake db:migrate
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake db:migrate
On the VMDB and non-VMDB appliances, update the Automate Model to the latest version. This resets the ManageIQ and Red Hat domains (base domains) to a new and upgraded version. Run the command appropriate to your environment to update the Automate Model:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake evm:automate:reset
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake evm:automate:reset
On the VMDB and dedicated database appliances, restart PostgreSQL:
[root@VMDB]# systemctl restart rh-postgresql95-postgresql [root@dedicatedDB]# systemctl restart rh-postgresql95-postgresql
On the VMDB and non-VMDB appliances, start the
evmserver
process:In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# systemctl start evmserverd
In a dedicated database or highly available environment, run this command on each non-VMDB appliance:
[root@non-VMDB]# systemctl start evmserverd
Chapter 5. Migrating from CloudForms 4.2 (CFME 5.7) to CloudForms 4.7 (CFME 5.10)
5.1. Overview
This procedure describes the process of migrating Red Hat CloudForms 4.2 (CFME 5.7) to Red Hat CloudForms 4.7 (CFME 5.10). This procedure does not necessarily include migration of all possible customer modifications, so it is recommended that you fully test any modifications before migrating your environment.
- Read through all of the steps in this procedure before beginning the migration process.
- CloudForms 4.5 and newer appliances require 12 GB memory, which is an increase from the 8 GB requirement in previous releases. Before migrating your appliances, adjust resources in your environment accordingly to avoid performance issues. See Migration Considerations in the Release Notes for more information.
- The addition of default SSL authentication in CloudForms 4.5 and newer for OpenShift Container Platform and Red Hat Virtualization providers may break existing connections to these providers after upgrading your environment. After migrating all appliances to CloudForms 4.7, edit any existing OpenShift Container Platform and Red Hat Virtualization providers to specify a security protocol and trusted certificate to use for connecting to the providers. See Managing Providers for configuration instructions.
You can classify the migration into three groups of appliances:
- VMDB appliance - An appliance with workers running, which also hosts its own database that other appliances can connect to.
- Non-VMDB appliance - An appliance with workers running which does not host a database. The appliance is connected to an external database.
- Dedicated database appliance - A CloudForms appliance or non-CloudForms virtual machine with no workers running on it; the appliance contains only a database for other appliances to connect to.
Migration Workflow Summary
In summary, the migration process from CFME 5.7 to CFME 5.10 follows this workflow:
Appliances must be offline during migration; ensure you plan for downtime when migrating.
- Back up appliances (optional but recommended).
Prepare appliances:
- Disable older CloudForms repositories and enable new repositories.
- Resize the disk space on the virtual machines hosting the appliances.
-
Shut down
evmserver
on the master or global appliance.
Migrate appliances:
- Update CFME packages on all appliances.
- Load the new version of the pglogical library on the VMDB and dedicated database appliances.
- Migrate the non-VMDB and VMDB appliance databases and update the Automate Model.
- Restart PostgreSQL on the VMDB and dedicated database appliances.
-
Restart
evmserver
on the VMDB and non-VMDB appliances.
- Configure replication after the migration process is complete and appliances are running once again.
5.2. Backing Up Current Appliances
These steps will not affect the operations of your CloudForms infrastructure. However, they will help ensure that you are able to roll back if required and replicate the network settings.
- Back up the databases of your CFME 5.7 appliances. Take a snapshot if possible.
Back up the following files for disaster recovery, noting which appliance each comes from:
-
/var/www/miq/vmdb/GUID
-
/var/www/miq/vmdb/REGION
-
During the upgrade, the iptables configuration file (
/etc/sysconfig/iptables
) is removed. If you have changed the iptables configuration from the default (runiptables --list -n
to see the current configuration), use the following command to back up the iptables configuration:# iptables-save > /etc/iptables.conf
You can restore your iptables configuration file with the following command:
# iptables-restore < /etc/iptables.conf
Alternatively, add this command to
/etc/rc.local
to reload the rules at every reboot.
For 5.7 appliances with the User Interface server role: Before migration, ensure that the Web Services role is enabled (it is enabled by default in CFME 5.7). If the Web Services role is disabled, it will not be turned on during the migration process. This role is required in CFME 5.10 to be able to log in to the user interface.
5.3. Preparing the Appliances for Migration
On all appliances:
Disable the CloudForms 4.2 (CFME 5.7) repositories:
# subscription-manager repos --disable=cf-me-5.7-for-rhel-7-rpms
NoteSee Enabling Supplementary and Optional Repositories in Using and Configuring Red Hat Subscription Manager for more information.
Enable the CloudForms 4.7 (CFME 5.10) repositories:
# subscription-manager repos --enable=rhel-7-server-rpms \ --enable=cf-me-5.10-for-rhel-7-rpms \ --enable=rhel-7-server-extras-rpms \ --enable=rhel-7-server-ansible-2.7-rpms \ --enable=rhel-7-server-rh-common-rpms \ --enable=rhel-server-rhscl-7-rpms
5.4. Resizing the Disk Space
CloudForms 4.7 (CFME 5.10) requires more disk space than previous CloudForms versions (CFME 5.8.0.17 and prior) because of the addition of built-in Ansible features. Before migrating your CloudForms 4.2 appliances to CloudForms 4.7, resize the virtual machine partition hosting the appliances to ensure sufficient space is available for the appliance.
Complete the following steps to resize the disk space, replacing filenames as needed:
Install the
xfsdump
tool for backing up filesystems:# yum -y install xfsdump
Back up the partition’s existing filesystem,
/repo
, to a temporary repository,/tmp/repo
:# xfsdump -F -f /tmp/repo /repo
Unmount the existing filesystem:
# umount /repo
Remove the logical volume:
# lvremove -f /dev/VG-CFME/lv_repo
Create a new 1GB logical volume in the existing volume group
lv_repo
:# lvcreate --yes -L 1GB -n lv_repo VG-CFME
Construct the volume path:
# mkfs.xfs /dev/VG-CFME/lv_repo
Mount the volume to
/repo
:# mount /dev/VG-CFME/lv_repo /repo
Restore the
/tmp/repo
filesystem data to the old filesystem:# xfsrestore -f /tmp/repo /repo
Resize the volume to allow sufficient space for the CloudForms 4.7 appliance:
# lvextend --resizefs --size +9GB /dev/VG-CFME/lv_var
5.5. Migrating from CFME 5.7 to 5.10
Perform the following steps on your CloudForms VMDB, non-VMDB and dedicated database appliances to migrate to CFME 5.10. Migrate all remote regions before migrating the global region. See Chapter 1, Ordering Migrations for more information.
Some steps are run on certain appliances. Ensure you wait for each command to finish before going to the next step.
- Connect to the appliance using SSH.
On the VMDB and non-VMDB appliances, stop the
evmserver
process:[root@VMDB]# systemctl stop evmserverd [root@non-VMDB]# systemctl stop evmserverd
Update packages on all appliances:
[root@VMDB]# yum update [root@non-VMDB]# yum update [root@dedicatedDB]# yum update
On the VMDB and dedicated database appliances, restart the server to load the new version of the
pglogical
library:[root@VMDB]# systemctl restart $APPLIANCE_PG_SERVICE [root@dedicatedDB]# systemctl restart $APPLIANCE_PG_SERVICE
On the VMDB and non-VMDB appliances, log out of the appliance, then log back in to fully reload Ruby.
ImportantFailure to log out of the old shell environment and back into a new one results in an error reporting a Ruby gem is missing.
If you did not log out and log back in and received the error message about the missing gem, you can re-login and continue with the next step. But if you ran
bundle install
after the error, you must runyum reinstall cfme-gemset
to fix the broken environment in order to continue.On the VMDB and non-VMDB appliances, change to the
vmdb
directory:[root@VMDB]# cd /var/www/miq/vmdb/ [root@non-VMDB]# cd /var/www/miq/vmdb/
On the VMDB and non-VMDB appliances, run the below command appropriate to your environment to migrate everything in the database to work with the latest 5.10 configuration:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake db:migrate
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake db:migrate
On the VMDB and non-VMDB appliances, update the Automate Model to the latest version. This resets the ManageIQ and Red Hat domains (base domains) to a new and upgraded version. Run the command appropriate to your environment to update the Automate Model:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake evm:automate:reset
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake evm:automate:reset
On the VMDB and dedicated database appliances, restart PostgreSQL:
[root@VMDB]# systemctl restart rh-postgresql95-postgresql [root@dedicatedDB]# systemctl restart rh-postgresql95-postgresql
On the VMDB and non-VMDB appliances, start the
evmserver
process:In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# systemctl start evmserverd
In a dedicated database or highly available environment, run this command on each non-VMDB appliance:
[root@non-VMDB]# systemctl start evmserverd
Chapter 6. Migrating from CloudForms 4.1 (CFME 5.6) to CloudForms 4.7 (CFME 5.10)
6.1. Overview
This procedure describes the process of migrating Red Hat CloudForms 4.1 (CFME 5.6) to Red Hat CloudForms 4.7 (CFME 5.10). This procedure does not necessarily include migration of all possible customer modifications, so it is recommended that you fully test any modifications before migrating your environment.
- Read through all of the steps in this procedure before beginning the migration process.
- CloudForms 4.5 and newer appliances require 12 GB memory, which is an increase from the 8 GB requirement in previous releases. Before migrating your appliances, adjust resources in your environment accordingly to avoid performance issues. See Migration Considerations in the Release Notes for more information.
- The addition of default SSL authentication in CloudForms 4.5 and newer for OpenShift Container Platform and Red Hat Virtualization providers may break existing connections to these providers after upgrading your environment. After migrating all appliances to CloudForms 4.7, edit any existing OpenShift Container Platform and Red Hat Virtualization providers to specify a security protocol and trusted certificate to use for connecting to the providers. See Managing Providers for configuration instructions.
You can classify the migration into three groups of appliances:
- VMDB appliance - An appliance with workers running, which also hosts its own database that other appliances can connect to.
- Non-VMDB appliance - An appliance with workers running which does not host a database. The appliance is connected to an external database.
- Dedicated database appliance - A CloudForms appliance or non-CloudForms virtual machine with no workers running on it; the appliance contains only a database for other appliances to connect to.
Migration Workflow Summary
In summary, the migration process from CFME 5.6 to CFME 5.10 follows this workflow:
Appliances must be offline during migration; ensure you plan for downtime when migrating.
- Back up appliances (optional but recommended).
Prepare appliances:
- Disable older CloudForms repositories and enable new repositories.
- Resize the disk space on the virtual machines hosting the appliances.
-
Shut down
evmserver
on the master or global appliance.
Migrate appliances:
- Update CFME packages on all appliances.
- Load the new version of the pglogical library on the VMDB and dedicated database appliances.
- Migrate the non-VMDB and VMDB appliance databases and update the Automate Model.
- Restart PostgreSQL on the VMDB and dedicated database appliances.
-
Restart
evmserver
on the VMDB and non-VMDB appliances.
- Configure replication after the migration process is complete and appliances are running once again.
6.2. Backing Up Current Appliances
These steps will not affect the operations of your CloudForms infrastructure. However, they will help ensure that you are able to roll back if required and replicate the network settings.
- Back up the databases of your CFME 5.6 appliances. Take a snapshot if possible.
Back up the following files for disaster recovery, noting which appliance each comes from:
-
/var/www/miq/vmdb/GUID
-
/var/www/miq/vmdb/REGION
-
During the upgrade, the iptables configuration file (
/etc/sysconfig/iptables
) is removed. If you have changed the iptables configuration from the default (runiptables --list -n
to see the current configuration), use the following command to back up the iptables configuration:# iptables-save > /etc/iptables.conf
You can restore your iptables configuration file with the following command:
# iptables-restore < /etc/iptables.conf
Alternatively, add this command to
/etc/rc.local
to reload the rules at every reboot.
For 5.6 appliances with the User Interface server role: Before migration, ensure that the Web Services role is enabled (it is enabled by default in CFME 5.7 and later). If the Web Services role is disabled, it will not be turned on during the migration process. This role is required in CFME 5.10 to be able to log in to the user interface.
6.3. Preparing the Appliances for Migration
On all appliances:
Disable the CloudForms 4.1 (CFME 5.6) repositories:
# subscription-manager repos --disable=cf-me-5.6-for-rhel-7-rpms
NoteSee Enabling Supplementary and Optional Repositories in Using and Configuring Red Hat Subscription Manager for more information.
Enable the CloudForms 4.7 (CFME 5.10) repositories:
# subscription-manager repos --enable=rhel-7-server-rpms \ --enable=cf-me-5.10-for-rhel-7-rpms \ --enable=rhel-7-server-extras-rpms \ --enable=rhel-7-server-ansible-2.7-rpms \ --enable=rhel-7-server-rh-common-rpms \ --enable=rhel-server-rhscl-7-rpms
6.4. Resizing the Disk Space
CloudForms 4.7 (CFME 5.10) requires more disk space than previous CloudForms versions (CFME 5.8.0.17 and prior) because of the addition of built-in Ansible features. Before migrating your CloudForms 4.1 appliances to CloudForms 4.7, resize the virtual machine partition hosting the appliances to ensure sufficient space is available for the appliance.
Complete the following steps to resize the disk space, replacing filenames as needed:
Install the
xfsdump
tool for backing up filesystems:# yum -y install xfsdump
Back up the partition’s existing filesystem,
/repo
, to a temporary repository,/tmp/repo
:# xfsdump -F -f /tmp/repo /repo
Unmount the existing filesystem:
# umount /repo
Remove the logical volume:
# lvremove -f /dev/VG-CFME/lv_repo
Create a new 1GB logical volume in the existing volume group
lv_repo
:# lvcreate --yes -L 1GB -n lv_repo VG-CFME
Construct the volume path:
# mkfs.xfs /dev/VG-CFME/lv_repo
Mount the volume to
/repo
:# mount /dev/VG-CFME/lv_repo /repo
Restore the
/tmp/repo
filesystem data to the old filesystem:# xfsrestore -f /tmp/repo /repo
Resize the volume to allow sufficient space for the CloudForms 4.7 appliance:
# lvextend --resizefs --size +9GB /dev/VG-CFME/lv_var
6.5. Additional Preparation for VMDB Appliances with Replication
Complete the following steps only on VMDB appliances:
These steps are only required on ruby replicated appliances. Appliances without this configuration can skip these steps.
This step must be completed before migrating the master VMDB appliance. On the subordinate region VMDB appliances, stop the Database Synchronization server role.
- In the CloudForms user interface, navigate to the specific server’s page by clicking Settings → Configuration, then click Settings in the accordion menu and select Server.
- On the Server tab under Server Control, clear the Database Synchronization role.
- Verify that the Database Synchronization role has stopped by navigating to Settings → Configuration, then click Diagnostics in the accordion menu and select Region.
- Click the Replication tab. The number for Current Backlog should be increasing.
- Connect to the VMDB appliance using SSH.
Shut down the
evmserver
process on the subordinate or remote database:# systemctl stop evmserverd
Change to the VMDB directory:
# cd /var/www/miq/vmdb/
Run the following to remove any installed rubyrep configuration. This will prevent errors when setting up pglogical after migration:
# bin/rake evm:dbsync:uninstall
Shut down the evmserver process on the master or global region:
# systemctl stop evmserverd
6.6. Migrating from CFME 5.6 to 5.10
Perform the following steps on your CloudForms VMDB, non-VMDB and dedicated database appliances to migrate to CFME 5.10. Migrate all remote regions before migrating the global region. See Chapter 1, Ordering Migrations for more information.
Some steps are run on only certain appliances. Ensure you wait for each command to finish before going to the next step.
- Connect to the appliance using SSH.
On the VMDB and non-VMDB appliances, stop the
evmserver
process:[root@VMDB]# systemctl stop evmserverd [root@non-VMDB]# systemctl stop evmserverd
Update packages on all appliances:
[root@VMDB]# yum update [root@non-VMDB]# yum update [root@dedicatedDB]# yum update
On the VMDB and non-VMDB appliances, log out of the appliance, then log back in to fully reload Ruby.
ImportantFailure to log out of the old shell environment and back into a new one results in an error reporting a Ruby gem is missing.
If you did not log out and log back in and received the error message about the missing gem, you can re-login and continue with the next step. But if you ran
bundle install
after the error, you must runyum reinstall cfme-gemset
to fix the broken environment in order to continue.On the VMDB and non-VMDB appliances, change to the
vmdb
directory:[root@VMDB]# cd /var/www/miq/vmdb/ [root@non-VMDB]# cd /var/www/miq/vmdb/
On the VMDB and non-VMDB appliances, run the below command appropriate to your environment to migrate everything in the database to work with the latest 5.10 configuration:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake db:migrate
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake db:migrate
On the VMDB and non-VMDB appliances, update the Automate Model to the latest version. This resets the ManageIQ and Red Hat domains (base domains) to a new and upgraded version. Run the command appropriate to your environment to update the Automate Model:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake evm:automate:reset
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake evm:automate:reset
On each VMDB appliance run postgres upgrade:
# /usr/bin/miq_postgres_upgrade.sh
ImportantWhen you run the script, you are asked to confirm whether to proceed with the operation. Your response must be either a capital Y or a capital N; all other values are rejected.
Before starting the new server, edit
/var/opt/rh/rh-postgresql95/lib/pgsql/data/postgresql.conf
file to ensure the configuration works correctly with PostgreSQL 9.5.NoteSome lines below are intentionally added in a commented-out fashion; these indicate the default values for particular parameters and are shown for informational purposes. See /var/opt/rh/rh-postgresql95/lib/pgsql/data/postgresql.conf for further documentation about configuring this file.
Under Checkpoints, remove and add the following lines as shown:
-checkpoint_segments = 15 # MIQ Value; -#checkpoint_segments = 3 # in logfile segments, min 1, 16MB each +#max_wal_size = 1GB +#min_wal_size = 80MB -wal_level = minimal # minimal, archive, or hot_standby +wal_level = 'logical' # MIQ Value (pglogical) -max_wal_senders = 0 # max number of walsender processes +max_wal_senders = 10 # MIQ Value (pglogical) max number of walsender processes +max_worker_processes = 10 # MIQ Value (pglogical) +max_replication_slots = 10 # MIQ Value (pglogical)
Under Kernel Resource Usage, edit the following line as shown:
-shared_preload_libraries = 'pglogical' # MIQ Value (change requires restart) +shared_preload_libraries = 'pglogical,repmgr_funcs' # MIQ Value (change requires restart)
Under Archiving, add the following line:
+wal_log_hints = on
Enable and start PostgreSQL:
# systemctl enable rh-postgresql95-postgresql && systemctl start rh-postgresql95-postgresql
On the VMDB and non-VMDB appliances, start the
evmserver
process:In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# systemctl start evmserverd
In a dedicated database or highly available environment, run this command on each non-VMDB appliance:
[root@non-VMDB]# systemctl start evmserverd
Chapter 7. Migrating from CloudForms 4.0 (CFME 5.5) to CloudForms 4.7 (CFME 5.10)
7.1. Overview
This procedure describes the process of migrating Red Hat CloudForms 4.0 (CFME 5.5) to Red Hat CloudForms 4.7 (CFME 5.10). This procedure does not necessarily include migration of all possible customer modifications, so it is recommended that you fully test any modifications before migrating your environment.
- Read through all of the steps in this procedure before beginning the migration process.
- CloudForms 4.5 and newer appliances require 12 GB memory, which is an increase from the 8 GB requirement in previous releases. Before migrating your appliances, adjust resources in your environment accordingly to avoid performance issues. See Migration Considerations in the Release Notes for more information.
- The addition of default SSL authentication in CloudForms 4.5 and newer for OpenShift Container Platform and Red Hat Virtualization providers may break existing connections to these providers after upgrading your environment. After migrating all appliances to CloudForms 4.7, edit any existing OpenShift Container Platform and Red Hat Virtualization providers to specify a security protocol and trusted certificate to use for connecting to the providers. See Managing Providers for configuration instructions.
You can classify the migration into three groups of appliances:
- VMDB appliance - An appliance with workers running, which also hosts its own database that other appliances can connect to.
- Non-VMDB appliance - An appliance with workers running which does not host a database. The appliance is connected to an external database.
- Dedicated database appliance - A CloudForms appliance or non-CloudForms virtual machine with no workers running on it; the appliance contains only a database for other appliances to connect to.
Migration Workflow Summary
In summary, the migration process from CFME 5.5 to CFME 5.10 follows this workflow:
Appliances must be offline during migration; ensure you plan for downtime when migrating.
- Back up appliances (optional but recommended).
Prepare appliances:
- Disable older CloudForms repositories and enable new repositories.
- Resize the disk space on the virtual machines hosting the appliances.
-
Shut down
evmserver
on the master or global appliance.
Migrate appliances:
- Update CFME packages on all appliances.
- Load the new version of the pglogical library on the VMDB and dedicated database appliances.
- Migrate the non-VMDB and VMDB appliance databases and update the Automate Model.
- Restart PostgreSQL on the VMDB and dedicated database appliances.
-
Restart
evmserver
on the VMDB and non-VMDB appliances.
- Configure replication after the migration process is complete and appliances are running once again.
7.2. Backing Up Current Appliances
These steps will not affect the operations of your CloudForms infrastructure. However, they will help ensure that you are able to roll back if required and replicate the network settings.
- Back up the databases of your CFME 5.5 appliances. Take a snapshot if possible.
Back up the following files for disaster recovery, noting which appliance each comes from:
-
/var/www/miq/vmdb/GUID
-
/var/www/miq/vmdb/REGION
-
During the upgrade, the iptables configuration file (
/etc/sysconfig/iptables
) is removed. If you have changed the iptables configuration from the default (runiptables --list -n
to see the current configuration), use the following command to back up the iptables configuration:# iptables-save > /etc/iptables.conf
You can restore your iptables configuration file with the following command:
# iptables-restore < /etc/iptables.conf
Alternatively, add this command to
/etc/rc.local
to reload the rules at every reboot.
For 5.5 appliances with the User Interface server role: Before migration, ensure that the Web Services role is enabled (it is enabled by default in CFME 5.7 and later). If the Web Services role is disabled, it will not be turned on during the migration process. This role is required in CFME 5.10 to be able to log in to the user interface.
7.3. Preparing the Appliances for Migration
On all appliances:
Disable the CloudForms 4.0 (CFME 5.5) repositories:
# subscription-manager repos --disable=cf-me-5.5-for-rhel-7-rpms
NoteSee Enabling Supplementary and Optional Repositories in Using and Configuring Red Hat Subscription Manager for more information.
Enable the CloudForms 4.7 (CFME 5.10) repositories:
# subscription-manager repos --enable=rhel-7-server-rpms \ --enable=cf-me-5.10-for-rhel-7-rpms \ --enable=rhel-7-server-extras-rpms \ --enable=rhel-7-server-ansible-2.7-rpms \ --enable=rhel-7-server-rh-common-rpms \ --enable=rhel-server-rhscl-7-rpms
7.4. Resizing the Disk Space
CloudForms 4.7 (CFME 5.10) requires more disk space than previous CloudForms versions (CFME 5.8.0.17 and prior) because of the addition of built-in Ansible features. Before migrating your CloudForms 4.0 appliances to CloudForms 4.7, resize the virtual machine partition hosting the appliances to ensure sufficient space is available for the appliance.
Complete the following steps to resize the disk space, replacing filenames as needed:
Install the
xfsdump
tool for backing up filesystems:# yum -y install xfsdump
Back up the partition’s existing filesystem,
/repo
, to a temporary repository,/tmp/repo
:# xfsdump -F -f /tmp/repo /repo
Unmount the existing filesystem:
# umount /repo
Remove the logical volume:
# lvremove -f /dev/VG-CFME/lv_repo
Create a new 1GB logical volume in the existing volume group
lv_repo
:# lvcreate --yes -L 1GB -n lv_repo VG-CFME
Construct the volume path:
# mkfs.xfs /dev/VG-CFME/lv_repo
Mount the volume to
/repo
:# mount /dev/VG-CFME/lv_repo /repo
Restore the
/tmp/repo
filesystem data to the old filesystem:# xfsrestore -f /tmp/repo /repo
Resize the volume to allow sufficient space for the CloudForms 4.7 appliance:
# lvextend --resizefs --size +9GB /dev/VG-CFME/lv_var
7.5. Additional Preparation for VMDB Appliances with Replication
Complete the following steps only on VMDB appliances:
These steps are only required on ruby replicated appliances. Appliances without this configuration can skip these steps.
This step must be completed before migrating the master VMDB appliance. On the subordinate region VMDB appliances, stop the Database Synchronization server role.
- In the CloudForms user interface, navigate to the specific server’s page by clicking Settings → Configuration, then click Settings in the accordion menu and select Server.
- On the Server tab under Server Control, clear the Database Synchronization role.
- Verify that the Database Synchronization role has stopped by navigating to Settings → Configuration, then click Diagnostics in the accordion menu and select Region.
- Click the Replication tab. The number for Current Backlog should be increasing.
- Connect to the VMDB appliance using SSH.
Shut down the
evmserver
process on the subordinate or remote database:# systemctl stop evmserverd
Change to the VMDB directory:
# cd /var/www/miq/vmdb/
Run the following to remove any installed rubyrep configuration. This will prevent errors when setting up pglogical after migration:
# bin/rake evm:dbsync:uninstall
Shut down the evmserver process on the master or global region:
# systemctl stop evmserverd
7.6. Migrating from CFME 5.5 to 5.10
Perform the following steps on your CloudForms VMDB, non-VMDB and dedicated database appliances to migrate to CFME 5.10. Migrate all remote regions before migrating the global region. See Chapter 1, Ordering Migrations for more information.
Some steps are run on only certain appliances. Ensure you wait for each command to finish before going to the next step.
- Connect to the appliance using SSH.
On the VMDB and non-VMDB appliances, stop the
evmserver
process:[root@VMDB]# systemctl stop evmserverd [root@non-VMDB]# systemctl stop evmserverd
Update packages on all appliances:
[root@VMDB]# yum update [root@non-VMDB]# yum update [root@dedicatedDB]# yum update
On the VMDB and non-VMDB appliances, log out of the appliance, then log back in to fully reload Ruby.
ImportantFailure to log out of the old shell environment and back into a new one results in an error reporting a Ruby gem is missing.
If you did not log out and log back in and received the error message about the missing gem, you can re-login and continue with the next step. But if you ran
bundle install
after the error, you must runyum reinstall cfme-gemset
to fix the broken environment in order to continue.On the VMDB and non-VMDB appliances, change to the
vmdb
directory:[root@VMDB]# cd /var/www/miq/vmdb/ [root@non-VMDB]# cd /var/www/miq/vmdb/
On the VMDB and non-VMDB appliances, run the below command appropriate to your environment to migrate everything in the database to work with the latest 5.10 configuration:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake db:migrate
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake db:migrate
On the VMDB and non-VMDB appliances, update the Automate Model to the latest version. This resets the ManageIQ and Red Hat domains (base domains) to a new and upgraded version. Run the command appropriate to your environment to update the Automate Model:
In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# rake evm:automate:reset
In a dedicated database or highly available environment, run this command on a single non-VMDB appliance pointed at that environment:
[root@non-VMDB]# rake evm:automate:reset
On each VMDB appliance run postgres upgrade:
# /usr/bin/miq_postgres_upgrade.sh
ImportantWhen you run the script, you are asked to confirm whether to proceed with the operation. Your response must be either a capital Y or a capital N; all other values are rejected.
Before starting the new server, edit
/var/opt/rh/rh-postgresql95/lib/pgsql/data/postgresql.conf
file to ensure the configuration works correctly with PostgreSQL 9.5.NoteSome lines below are intentionally added in a commented-out fashion; these indicate the default values for particular parameters and are shown for informational purposes. See /var/opt/rh/rh-postgresql95/lib/pgsql/data/postgresql.conf for further documentation about configuring this file.
Under Checkpoints, remove and add the following lines as shown:
-checkpoint_segments = 15 # MIQ Value; -#checkpoint_segments = 3 # in logfile segments, min 1, 16MB each +#max_wal_size = 1GB +#min_wal_size = 80MB -wal_level = minimal # minimal, archive, or hot_standby +wal_level = 'logical' # MIQ Value (pglogical) -max_wal_senders = 0 # max number of walsender processes +max_wal_senders = 10 # MIQ Value (pglogical) max number of walsender processes +max_worker_processes = 10 # MIQ Value (pglogical) +max_replication_slots = 10 # MIQ Value (pglogical)
Under Kernel Resource Usage, edit the following line as shown:
-shared_preload_libraries = 'pglogical' # MIQ Value (change requires restart) +shared_preload_libraries = 'pglogical,repmgr_funcs' # MIQ Value (change requires restart)
Under Archiving, add the following line:
+wal_log_hints = on
Add the following line in the /var/opt/rh/rh-postgresql95/lib/pgsql/data/pg_ident.conf file:
+usermap postgres root
Add the following line in the /var/opt/rh/rh-postgresql95/lib/pgsql/data/pg_hba.conf file:
+host replication all all md5
Enable and start PostgreSQL:
# systemctl enable rh-postgresql95-postgresql && systemctl start rh-postgresql95-postgresql
On the VMDB and non-VMDB appliances, start the
evmserver
process:In a single (standalone database) or replicated environment, run this command on each VMDB appliance:
[root@VMDB]# systemctl start evmserverd
In a dedicated database or highly available environment, run this command on each non-VMDB appliance:
[root@non-VMDB]# systemctl start evmserverd
Chapter 8. Updating CloudForms
This chapter details applying software package minor updates (referred to as errata) to CloudForms 4.7 appliances.
Appliances must be registered to Red Hat Subscription Manager and subscribed to the update channels required by CloudForms in order to access updates. See Registering Red Hat CloudForms in General Configuration to register and subscribe the appliance.
8.1. Updating the CloudForms Application
An important part of securing CloudForms is to ensure your appliances use the latest software packages.
The Red Hat Updates tab in the CloudForms user interface enables you to check for updates and update registered appliances. Any services requiring a restart to apply updates are automatically restarted as part of the Red Hat Updates process.
Using the Red Hat Updates tab only applies software updates for the CloudForms application. To run the update from the command line, run yum update cfme*
. See ] for instructions on applying Red Hat errata. To upgrade your appliance to CloudForms 4.7 from an earlier version, see xref:migrate_45-47[ and Chapter 5, Migrating from CloudForms 4.2 (CFME 5.7) to CloudForms 4.7 (CFME 5.10).
To apply updates to the CloudForms application:
- From the settings menu, select Configuration.
- Select Region in the accordion menu and click the Red Hat Updates tab.
- Click Check For Updates to search the Content Delivery Network (CDN) for any updated CloudForms packages. If an appliance update is available, it will be listed with the available version.
- Click Apply CFME Update to install and update CloudForms packages. The CloudForms service will be automatically restarted as needed.
If the appliance is registered to Red Hat Satellite, you can use content views to manage updates for CloudForms. For more information, see Creating Content Views in the Red Hat Satellite 6 Content Management Guide.
The following options are available in the Appliance Updates section of Red Hat Updates:
Table 8.1. Options Available in Appliance Updates
Option | Use |
---|---|
Refresh List | Refreshes the list of appliances. |
Check for Updates |
Checks for all available CloudForms updates using |
Register |
Attempts to register the appliance if it is not already registered. CloudForms subscribes to the |
Apply CFME Update |
Applies updates to CloudForms packages only. Specifically, this option runs the |
8.2. Updating All Packages on the Appliance
You can apply updates to the appliance using the yum command or Red Hat Satellite. This updates all RPMs on the appliance, not just the CloudForms packages. Yum can be used at any time to update any single package or the entire appliance to any new or updated packages available on the subscription.
Updates to the the operating system, CloudForms application or dependent packages may introduce incompatibilities in customized environments. Before applying updates to the appliance, back up the appliance or take a snapshot so that changes can be reverted in production environments if needed.
Scheduled downtime is required while updating system packages for the following reasons:
- Some updates may interrupt CloudForms operations.
- Updates for the PostgreSQL database server suspend CloudForms operations.
- System updates may require a reboot of the CloudForms appliance.
To update all packages on the appliance using yum
, follow the procedure below. To update packages on the appliance using Red Hat Satellite, see Viewing and Applying Errata and Configuring and Running Remote Commands in the Red Hat Satellite 6 documentation for more information.
Log into each appliance console as the root user and perform the following steps:
Stop the CloudForms application (the evmserver process) with the following command:
# systemctl stop evmserverd
Apply the software updates:
# yum update
ImportantDo not reboot or restart yet.
Log into each server containing an internal database and perform the following steps:
Stop the database with the following command:
# systemctl stop rh-postgresql95-postgresql.service
Apply the software updates:
# yum update
Reboot the server unless the errata or the command
needs-restarting
advises a restart is safe:# systemctl restart rh-postgresql95-postgresql.service
Log into the appliance console on each appliance as the root user and perform the following steps:
Reboot the server unless the errata or the command
needs-restarting
advises a restart is safe:# reboot
-
If there is a warning in the Automation → Automate → Explorer page about Automation not being up to date, reset the default Automate domains (ManageIQ and RedHat) by navigating to Automation → Automate → Import/Export and clicking the reset button. You can also reset the default Automate domains via command line by running the rake command:
rake evm:automate:reset
. - If you don’t update the Automate domains, it can cause issues in many areas including provisioning, retirement, approval, and quota.