Skip to content

SUSE Manager 3.2 to 4.0 Migration tips

Jump to bottom
dvosburg edited this page Mar 19, 2020 · 7 revisions

Follow the SUSE Manager 4 Installation tips for preparing the "target" server for migration

https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/upgrade/migrate-3x-4x.html#_prepare_to_migrate

Prior to the Scheduled Migration Downtime

  • Run the migration script FIRST with the '-r' option:

/usr/lib/susemanager/bin/mgr-setup -r

This copies the file-based (non-database) SUSE Manager elements. You can copy this data by running the migration script with the '-r' option at any time before your scheduled migration process, or multiple times as needed. Copying the data this way before scheduled migration can significantly reduce the amount of downtime required.

NOTE: You can even safely interrupt and restart this process. Since it uses rsync technology, it will detect what has already completed successfully and continue replicating files.

Disk partition sizing on the target server

  • Ensure you are sizing the target server to have more than enough space to accommodate what you had on 3.2. This is especially true of /var/spacewalk, where the migration will create a dump of your 3.2 database for importing

At the Scheduled Migration Downtime

  • Run the migration script with the '-m' option.

/usr/lib/susemanager/bin/mgr-setup -m

Once this starts, it will DISABLE the SUSE Manager services, so consider this in your downtime estimation. The '-m' option also will include the '-r' functionality to ensure files are up to date when services are stopped. For this reason, running it with the '-r' option ahead as recommended above will lower the needed downtime window.

  • When the '-m' migration completes, you receive a 'migration successful` message. You will need to reconfigure the network of the target system to either use the same IP address and host name as the original system, or manage your DNS to point to the new IP. You will also need to restart the target system before it can be used.

The goal is to have no need to re-register managed instances, but that your new SUSE Manager 4 server shows all the registered instances, system groups, software channels, activation keys, etc. that were on your 3.2 server.

  • You may need to access the old 3.2 server for things you may have missed in the migration process. For example:
    • scripts located in /usr/local/bin
    • ISO files mounted for any Autoinstallation Distributions For that reason it is wise to change the IP address of your 3.2 server before powering it off after you receive the 'migration successful` message. One way to do this is to edit the /etc/sysconfig/network/ifcfg-eth0 file BEFORE shutdown. Then when you power it up, use this new IP to reach it to recover any files that may not have been migrated.
Clone this wiki locally