Well, SUSE Linux Enterprise Server 15 has been released for a while and SLES 15 SP1 is on the horizon. While there will be another service pack in the SLES 12 series, SLES 12 SP5, many people have expressed interest to move to SLES 15 from SLES 12. After providing a “Follow this long tedious manual process” procedure for the SLES 11 to SLES 12 migration that was certainly not for the faint of heart we wanted to provide a better easier way to migrate an instance while at the same time avoiding some of the pitfalls that are inherent in a running system migration. This gave birth to the suse-migration-services project. We are happy to announce the availability of the migration in the SLES 12 Public Cloud module.
Before we get to the details here is how it works, as root run:
zypper in SLE15-Migration suse-migration-sle15-activation
That was easy! The preconditions are that the system is registered, on-demand instances are automatically registered, and BYOS instances should be registered to SCC, SMT, or RMT.
The process will take a while, and you can do other stuff or take a well deserved break. How do you know things are done?
Once you are able to login with your regular user setup the system has been migrated, well at least that is the expected result. A bit more below.
Let’s take a look what happens under the covers. The SLE15-Migration package delivers a live image and the suse-migration-sle15-activation package modifies the grub configuration such that on reboot the system will boot into the live image. The live image itself is configured such that it will automatically upgrade the system. All this happens while the systemdisk of the server to be migrated is not actively used by the system. Therefore there is no opportunity for the system to get into an inconsistent state. After the migration is finished the system will reboot and your instance will be running on SLES 15. The migration is supported with SLES 12 SP4 as the origin and SLES 15 will be the target, same versions for SLES For SAP. Please also consult the documentation.
If things should go wrong the system, when possible, will be rolled back to it’s original state. In order to debug a migration one can place /etc/sle-migration-service on the system to be migrated. This will prevent the reboot process and the migration can be tested interactively by logging into the live system. It is possible to ssh into the system during migration or if the debug file exists with
Existing ssh keys are copied into the migration system, but the host keys will be different. For those that rather watch than take a break you can login to the migration system and run ‘top‘. You’ll find that ‘zypper’ is running and doing it’s upgrade magic. If you interrupt the process your system is most likely not in a state where it can be recovered, thus to prevent any accidents we recommend not to login while the migration is in progress. The ‘migration‘ user has sudo access. The log for the migration can be found in /var/log/distro_migration.log
There are some caveats to consider
- Files marked as configuration files in RPM packages and modified will have a corresponding ‘.rpmnew’ version in the same location.
- Public Cloud instances from SUSE images have a custom ‘/etc/motd‘ file that makes reference the distribution version this needs to be modified manually
- Repositories not registered via SUSEConnect and added to the system manually will remain untouched.
- For Public Cloud instances the metadata will not change, as far as the cloud framework is concerned you will still be running a SLES 12 SP4 instance even if you migrated the instance to SLES 15. This cannot be changed.
- Migration is only possible for systems that have direct access to the root file system by the boot loader
- Migration is only possible for systems that use unencrypted root file systems, at the OS level. Encrypting the root device using a cloud framework encryption mechanism happens at a different level.
We’d also like to thank our beta testers that provided valuable feedback during development.