Keep Services Available During a SLES 15 SP5 to SP6 Upgrade

A short maintenance window is hard to schedule when a SLES server runs a customer-facing service. SUSE supports online service-pack migration from SLES 15 SP5 to SP6, but the upgraded machine still needs a reboot; “online” does not mean reboot-free. To keep an application reachable, upgrade redundant nodes one at a time or build an SP6 replacement and move traffic to it. A single server cannot keep its own operating system available while it reboots.

Illustrative scenario: A fictional team runs a web application across three SLES 15 SP5 nodes behind a load balancer. The application can serve requests from the other two nodes while one node is maintained. The sequence below shows how that team could migrate the cluster; it is an example, not a claim that a test was performed or that every cluster can tolerate a node outage.

1. Choose a path that matches the service

For a SLES 15 SP5 to SP6 move, SUSE documents both online and offline upgrade methods. The online method uses YaST migration or zypper migration while the operating system is running, then requires a system restart after the migration. Package changes may also restart services, so online migration alone cannot guarantee application continuity.

Use the SLE High Availability rolling-upgrade procedure only if your workload is already protected by a supported, healthy cluster. The cluster must retain quorum and enough capacity to run the service with a node offline. An ordinary load balancer without application redundancy, or a two-node cluster that loses quorum when one node stops, is not enough. If the server is standalone, use a parallel SP6 host and a tested workload/data cutover to maintain reachability; otherwise schedule downtime for its reboot.

2. Check the target and prepare a recovery plan

Before touching the cluster, verify the starting release, registration, repositories, and supported extensions. SUSE lists SLES 15 SP5 to SP6 as a supported path. Online migration requires the machine to be registered with SUSE Customer Center or a local RMT server; SUSE Manager clients must use the Manager client-migration procedure instead of running zypper migration directly. The available target can depend on registered products and extensions.

As of January 1, 2026, SUSE’s release information says SLES 15 SP6 has moved to LTSS. Confirm that your subscription and registration source currently expose the SP6 target before scheduling this specific migration. If it is not offered, do not force a repository change to imitate a supported migration.

Back up application data and configuration using the application’s supported method, and confirm that you can restore them. Review the SLE HA upgrade guide and SP6 release notes for your extensions, databases, storage, and hardware. In the fictional cluster, the operator also checks quorum, fencing, replication health, spare capacity, load-balancer health checks, and a tested way to move traffic away from each node. A snapshot can aid rollback on supported Btrfs root setups, but it does not replace application or database backups.

3. Upgrade one drained node at a time

For each node, follow the SLE HA rolling-upgrade procedure and your cluster’s runbook. Never upgrade multiple nodes at once unless the product-specific procedure explicitly allows it.

1. Confirm the remaining nodes can serve the workload. Check application health and cluster status. Move or drain traffic from the node using the documented controls for your load balancer and cluster resources. Do not proceed if the remaining nodes cannot preserve quorum or meet the service’s minimum capacity.
2. Stop the cluster stack on that node. SUSE warns that leaving the cluster resource manager active during the software update can cause fencing of active nodes. On the node selected for maintenance, run:

sudo crm cluster stop

3. Start the service-pack migration and inspect the proposal. Run the documented Zypper migration command:

sudo zypper migration

Select SLES 15 SP6 only if it appears as an available target. Read the repository and package plan, especially packages proposed for removal or downgrade, and stop if the changes are unexpected. Do not accept a plan you have not reviewed. The exact package list varies with installed software and registered extensions.

4. Reboot the upgraded node. After Zypper reports a successful migration, restart the machine so it boots the SP6 kernel and services:

sudo reboot

5. Rejoin and verify before moving to the next node. After the node returns, start its cluster stack:

sudo crm cluster start
sudo crm status

Wait until the cluster reports the node joined and resources are healthy, then restore it to service according to your runbook. Check the application from outside the cluster. Only then repeat the process for the next node. SUSE permits mixed versions only briefly during a rolling upgrade and instructs administrators to complete the cluster upgrade within one week.

4. Verify the service, not just the operating-system label

After all nodes are upgraded, confirm their release with cat /etc/os-release, inspect cluster health with crm status, and check failed systemd units with systemctl --failed. Then test the actual application through its normal client-facing address, including the health checks, database or storage access, and any scheduled jobs that matter to users. Review migration logs and confirm the expected repositories and extensions are active on every node.

A successful OS migration does not prove that every application dependency is compatible or that no request was interrupted. If the application cannot tolerate a node failover, use a blue-green deployment with validated data replication and a controlled endpoint switch, or plan a maintenance window. For exact command options and support conditions, consult SUSE’s SLES 15 SP6 online-upgrade guide, supported upgrade paths, SLE HA rolling-upgrade procedure, and the SUSE Multi-Linux Manager 5.1 release notes for the SP6 lifecycle transition note.