Product Migration

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 SP1 to SUSE Linux Enterprise Server 15 SP2.

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.1 to 15.2, or

  • openSUSE Leap 15.1 to SUSE Linux Enterprise Server 15 SP1, or

  • openSUSE Leap 15.5 to SUSE Linux Enterprise Server 15 SP5

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

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/sles/15-SP3/html/SLES-all/cha-upgrade-paths.html#sec-upgrade-paths-supported.

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 Client - Major Version Upgrade.

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

1. Perform a 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 uptodate, 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.

Procedure: Performing a 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.

2. 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 product mass migration operation is dangerous. Be careful not to upgrade systems unintentionally. The process should be tested thoroughly. At least, do a dry-run first.

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.

To see syntax usage and options for system_scheduleproductmigration, run:

spacecmd system_scheduleproductmigration help

2.1. Perform a Product Mass Migration

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.

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

2.2. Product Mass Migration 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 were added to the group.

Any systems that you are not intending to upgrade at this time, should be removed from the group.
Procedure: Adding Systems to the Group

  1. For more information about adding clients to groups, see client-configuration:system-groups.adoc#_add_clients_to_groups.

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. It is important that all systems in the group support the same "migration target."

You will get the targets for all the systems in the group, when you run:

spacecmd -- system_listmigrationtargets group:mpm-target-sles15sp3

Only select a target, which is reported for all systems. This command output a string of "IDs." The string is the identifier for the MIGRATIONTARGET of the other command.
Procedure: Running the Mass Migration Command

  1. 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

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

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

For more information, see spacecmd — system_scheduleproductmigration help.

2.3. Mandatory Syntax

<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

  1. -s START_TIME

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

  3. -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, you will see the command output with the following for each scheduled system:

  1. Scheduling Product migration for system mpm-sles152-1

  2. 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.