In-place Upgrade of SUSE Linux Enterprise Server with SUSE Manager

Table of Contents

1. Use Case
2. Outcome
3. Step-by-step Preparation Instructions
4. Migration of Clients

This workflow shows how to automatically complete the task of in-place SUSE Linux Enterprise Server instances upgrade with SUSE Manager Server.

1. Use Case

In-place migration is benefitial when:

migrating large number of the older SUSE Linux Enterprise Server is time-consuming
you are looking for a way to automate migrations

2. Outcome

Successful completion of this workflow results in consistent, supportable outcomes.

3. Step-by-step Preparation Instructions

This workflow is complex and time-consuming. Make sure that adequate testing is done before deploying the procedure in live environment.

Procedure: Prepare the SUSE Manager Server for Provisioning

Create a SUSE Manager Content Lifecycle Management project for your distribution. Choose a short-but-descriptive prefix in the name, including all source channel modules. Add Filters as needed. Add at least one Environment.
Create an Activation Key that includes the filtered project channels.
(Optional) Create a bootstrap script. The profile will not need it, because it is managed in the AutoYaST.
Create a /var/spacewalk/iso directory, and for SLES 15 SP2 and following, copy the Full iso (>10 GB) there. Create a mount point for it, such as /opt/install/15sp3 and mount the ISO there. Ensure this path gets re-mounted at boot time.
Create an Autoinstallation Distribution in SUSE Manager for each base channel to which you will migrate.
1. In the Distribution, reference the specific Base Channel to match the base to which you might migrate, for example the base channel of your CLM project Environment Lifecycle.
2. Label the Distribution something that references your specific Base Channel.
3. Set the Installer Generation to match your specific version of SUSE Linux Enterprise Server (12, 15, etc.).
4. The kernel options will be automatically populated when you click Create Autoinstallable Distribution.
You may create more Distributions depending on the Base Channel you need to assign, and you can re-use the same Tree Path for the boot media if required.
Click on Profiles, and upload Kickstart/AutoYaST file for each target SUSE Linux Enterprise Server distribution, service pack and channels you wish to migrate to.
1. This profile will be associated with the activation key and autoinstallation distribution created above.
2. Cut-and-paste a Profile template as the basis for what you upload, assign it the Autoinstall tree you created as a Distribution above.
3. Do not put anything in the Virtualizaton Type box, and click Create.
Once created, your profile will now have some new fields on this Details page. In the Kernel Options line on this Details page, put in
```
autoupgrade=1 insecure=1 useonlinerepo
```
This will tell your profile to treat its install as an upgrade, and allow http access to the SUSE Manager Server to obtain installer updates without needing to go to SUSE Customer Center.
Click the variables tab in your Autoinstallation Profile to specify CLM prefix, Activation Key, Distribution tree, and Organization:

Sample Variables:
- registration_key=1-15sp1-demo-test
- org=1
- channel_prefix=15sp1-demo-test
- distrotree=15sp1-demo-test

Edit the AutoYaST profile itself in a tool where you can use cut-and-paste for the channels in your profile. Use variables in your profiles where possible.

Published profiles can be used as a starting point.

For profile files, see https://github.com/SUSE/manager-build-profiles.

The profiles follow AutoYaST XML guidelines, and for an in-place upgrade there are several important sections:

Add-ons - the repositories used in the upgrade

<listentry>
<ask_on_error config:type="boolean">true</ask_on_error>
#if $channel_prefix != ""
<media_url>https://$redhat_management_server/ks/dist/child/$channel_prefix-sle-manager-tools15-pool-$arch-sp3/$distrotree</media_url>
#else
<media_url>https://$redhat_management_server/ks/dist/child/sle-manager-tools15-pool-$arch-sp3/$distrotree</media_url>
#end if
<name>$channel_prefix SLE-15-Manager-Tools Pool</name>
<product>sle-manager-tools</product>
</listentry>

Be sure to include all (and only) the relevant modules (both Pool and Updates) to be used in the migration. In migration, it is recommended to add all available modules, as the location of certain packages changes with new major versions.

After finishing the preparation, proceed with the actual migration.

4. Migration of Clients

Procedure: Migrating Clients

Prior to migration, be sure to check Software → Non-Compliant. This will show any orphaned packages on your system - those SUSE Manager does not find in any assigned channel. Make sure this list is very small or empty, and that you can account for all the packages there. Delete any that are unnecessary.

+ . Before provisioning, issue the following Remote Command to the systems you wish to upgrade to remove the existing SUSE Manager channels during the upgrade process:

rm -rf /etc/zypp/repos.d/susemanager*

+ . Assign your Autoinstallation Profile in System Details → Provisioning for one system, or in the Provisioning tab in SSM for as many systems as you need. SUSE Manager provisioning then auto-assigns a Reactivation Key to this system, that is referenced in the provisioning process. If you need to perform the upgrade through a particular SUSE Manager Proxy you will need to group just those systems together in SSM.

+ image::wf-inplaceMigration-06.png[scaledwidth=80%]

+ image::wf-inplaceMigration-07.png[scaledwidth=80%]

SUSE Manager creates the proper entry in /etc/grub.d/ for the reinstallation, and boots the selected systems to that entry. The Profile you created above will be used to drive automated upgrade, following which your system will use the reactivation key (one time), associating the upgraded system with the previous SUSE Manager profile.

The Session Status screen in SUSE Manager will not be updated real-time. Instead, watch the target system console to track progress. If you are updating an instance on a hyperscaler like AWS you may be able to get screenshots of the console.