Product Migration

1. Introduction

Product migration allows you to upgrade SLE-based client systems from an Service Pack (SP) level to a later one. For example, you can migrate SUSE Linux Enterprise Server 15 SP5 to SUSE Linux Enterprise Server 15 SP6. You can also upgrade clients such as Red Hat Enterprise Linux or CentOS to SUSE Liberty Linux.

Product migration requires that all repositories which are enabled on the client and which should be migrated must be valid, otherwise the migration will abort.

Uyuni supports the following migration paths:

1.1. Migration within the same major version

Product migration is for upgrading within the same major version. You cannot use product migration to migrate from SUSE Linux Enterprise Server 12 to SUSE Linux Enterprise Server 15. For more information about major upgrades, see Major Version Upgrade.

1.2. Migration of openSUSE Leap to a later minor version or to the corresponding SUSE Linux Enterprise Server SP

You can also migrate openSUSE Leap to a later minor version or to the corresponding SUSE Linux Enterprise Server SP level, for example:

  • openSUSE Leap 15.5 to 15.6

  • openSUSE Leap 15.6 to SUSE Linux Enterprise Server 15 SP6

1.3. Migration of SUSE Linux Enterprise Server to the corresponding SUSE Linux Enterprise Server for SAP Applications SP

You can also migrate SUSE Linux Enterprise Server to the corresponding SUSE Linux Enterprise Server for SAP Applications SP level, for example:

  • SUSE Linux Enterprise Server 15 SP5 to SUSE Linux Enterprise Server for SAP Applications 15 SP5

In SUSE Linux Enterprise Server 12 and later, SUSE supports service pack skipping if SUSE Customer Center provides it. For example, you can upgrade from SUSE Linux Enterprise Server 15 to SP2, without installing SP1.

For supported SUSE Linux Enterprise Server upgrade paths, see https://documentation.suse.com/en-us/sles/15-SP6/html/SLES-all/cha-upgrade-paths.html#sec-upgrade-paths-supported.

  • All recommended extensions are automatically enabled when you migrate.

  • During migration, Uyuni automatically accepts any required licenses (EULAs) before installation.

2. Single System Migration

Before starting the product migration:

  • Ensure there are no pending updates or patches. Check the System Status on the client system’s Details  Overview page, and install all offered updates or patches. If your client system is not up to date, product migration may fail.

  • Make sure all the channels of the target product are fully synchronized. To check the synchronization status in the Web UI, navigate to the Admin  Setup Wizard  Products page.

  • Ensure you have a working system backup available, in case of an emergency. Product migration does not have a rollback feature. When the migration procedure has begun, rolling back is not possible.

Procedure: Performing a Single System Migration

  1. From the Systems  Overview page, select a client.

  2. From the system details page of the client, navigate to the Software  Product Migration tab.

  3. Select the target migration path and click Select Channels.

  4. From the Product Migration - Channels page select the correct base channel, including Mandatory Child Channels and any additional Optional Child Channels.

  5. OPTIONAL: Check Allow Vendor Change to allow packages that have changed vendors to be installed. If this occurs, a notification is shown with details before the migration is started.

    To migrate openSUSE Leap to SUSE Linux Enterprise Server, you must check the Allow Vendor Change option.

  6. Click Schedule Migration when your channels have been configured properly.

3. Product Mass Migration

If you want to migrate a large number of clients to the next SP version, you can use Uyuni API calls.

The spacecmd commandline tool provides a system_scheduleproductmigration sub command, which can be used to schedule a migration for a large number of clients to the next minor version.

3.1. Perform a Product Mass Migration

The product mass migration operation is dangerous and the process should be tested thoroughly. At least, do a dry-run first.

Be careful not to upgrade systems unintentionally.
Procedure: Performing a Product Mass Migration

  1. List available migration targets, and take note of the system IDs you want to migrate:

    spacecmd api -- system.listMigrationTargets -A 1000010001

  2. For each system ID, call listMigrationTarget and check that the desired target product is available.

    • If the system ID has an available target, call system.scheduleProductMigration.

    • If the desired target is not available, skip the system.

  3. Adapt this template for your environment:

    target = '[....]'
basechannel = 'channel-label'
system_ids = [1, 2, 3]

session = auth.login(user, pass)
for system in system_ids
  if system.listMigrationTargets(session, system).ident == target
    system.scheduleProductMigration(session, system, target, basechannel, [], False, <now>)
  else
    print "Cannot migrate to requested target -- skipping system"
  endif
endfor

3.2. Example: SLES 15 SP2 to SLES 15 SP3

For this example, a group will be created temporarily to facilitate the mass migration.

Procedure: Creating a Mass Product Migration Group

  1. In the Uyuni Web UI, navigate to Systems  System Groups, and click Create Group.

  2. Name the group mpm-target-sles15sp3.

    • Only systems subscribed to the same base channel should be added to the created group. In the example, only systems subscribed to SLE-Product-SLES15-SP2-Pool for x86_64 should be added to the group.

      For more information about adding clients to groups, see System Groups.

Procedure: Adding Systems to the Group

  1. Get the targets for all the systems in the group by running:

    spacecmd -- system_listmigrationtargets group:mpm-target-sles15sp3

  2. The command output a string of "IDs."

    • Only select a target, which is reported for all systems.

    • The string is the identifier for the MIGRATIONTARGET of the other command.

      The spacecmd sub-commands system_scheduleproductmigration and system_listmigrationtargets are looping over all systems that are part of the group.

      If there are 100 systems in the group, you will see 100 actions scheduled.

      All systems in the group must support the same migration target.
Procedure: Running the Mass Migration Command

  1. The syntax for the system_scheduleproductmigration command is as follows:

    spacecmd -- system_scheduleproductmigration <SYSTEM> <BASE_CHANNEL_LABEL> \
    <MIGRATION_TARGET> [options]

  2. For this example to upgrade all systems in the group mpm-target-sles15sp3 from SLES 12 SP2 to SLES 15 SP, enter on the command line:

    spacecmd -- system_scheduleproductmigration group:mpm-target-sles15sp3 \
    sle-product-sles15-sp3-pool-x86_64 "[190,203,195,1242]" -d

3.2.1. Mandatory Syntax Explained

To see syntax usage and options for system_scheduleproductmigration, run:

spacecmd system_scheduleproductmigration help
<SYSTEM>

For this example we will use the group we created to select all of the systems from that group:

group:mpm-target-sles15sp3
<BASE_CHANNEL_LABEL>

This is the label for the target base channel. In this case, the system is being upgraded to SLES 15 SP3, and the label is sle-product-sles15-sp3-pool-x86_64.

To see a list of all base channels currently mirrored, run:

spacecmd softwarechannel_listbasechannels

Keep in mind you cannot upgrade to a channel unless it is an available target for your current base channel.

<MIGRATION_TARGET>

To identify this value for systems in the group group:mpm-target-sles15sp3, run:

spacecmd -- system_listmigrationtargets group:mpm-target-sles15sp3

The MIGRATION_TARGET parameter must be passed in the following format; note necessary shell quotation to prevent sideeffects with brackets:

"[190,203,195,1242]"
Options

  • -s START_TIME

  • -d pass this flag, if you want to do a dry run (it is recommended to run a dry run before the actual migration)

  • -c CHILD_CHANNELS (comma-separated child channels labels with no spaces)

    In this case we included the -d option, which can be removed after a successful dry run.

If successful, the command output for each scheduled system will look like this:

Scheduling Product migration for system mpm-sles152-1
Scheduled action ID: 66

You can also track the action, in this case the dry run, in the Web UI for a given system in the group. From the system details page of the client, navigate to Events  History. If there are any failures during the dry run, the system should be investigated.

If all is well, the -d option can be removed from the command to run the real migration. After the migration is complete, you can reboot the system from the Uyuni Web UI.