Switching Licensing Models on Google Cloud For SLES and SLES For SAP Instances (Flexible Licenses)

On August 4th, 2025 Google introduced a new feature in Google Compute Engine (GCE) that affords users the ability to switch instances between billing flavors. This feature is supported for SUSE Linux Enterprise Server and SUSE Linux Enterprise Server For SAP applications.

What is it?

The License Management feature implements the ability for an instance to be migrated from a Bring Your Own Subscription (BYOS) billing model to a Pay As You Go (PAYG) billing model and vice-versa. This provides a solution for a number of use cases, including:

1. Adapting to changing workloads: For instances running workloads that are periodic or don’t require 24/7 operation, users can switch to a PAYG model to stop incurring subscription costs when the instance is not in use. This frees up a subscription to be used on another system that does require an always-on model.
2. Maximizing cloud commit utilization: Customers who have signed a Google Cloud Committed Use Discount (CUD) can switch their BYOS instances to a PAYG model to “burn down” their commit and optimize costs.

How does it work?

There are two parts to licensing in the Public Cloud, the outside of the instance, i.e. how Google Compute Engine sees and treats the instance and the inside of the instance, i.e. how the running system behaves.

In GCE the license is attached to the root volume of an instance. A license is used for tracking an instance and can have a charge associated with it. For example we have license identifiers for our BYOS images and for our PAYG images. The license ids associated with the SLES and SLES For SAP BYOS images do not trigger a charge in addition to the GCE infrastructure costs, while the license codes for the PAYG images do. In order to find the license id for your running instance you can run the following command.

gcloud compute instances describe --project $THE_PROJECT_WHERE_THE_INSTANCE_IS_RUNNING --zone $THE_ZONE_IN_WHICH_THE_INSTANCE_IS_RUNNING $INSTANCE_NAME

For a SUSE Linux Enterprise Server 15 SP7 PAYG instance the above command, when properly substituted will contain https://www.googleapis.com/compute/v1/projects/suse-cloud/global/licenses/sles-15 marked with licenses:. More on license ids later.

Until the flexible license feature was introduced the license associated with the root volume of an instance was immutable. With the new feature it is now possible to switch the associated license code. Changing the license is a command-line operation using the gcloud command line tool as follows:

gcloud compute disks update $INSTANCE_NAME --zone $THE_ZONE_IN_WHICH_THE_INSTANCE_IS_RUNNING --replace-license=$THE_CURRENT_ATTACHED_LICENSE,$THE_NEW_LICENSE_TO_USE

For switching a SUSE Linux Enterprise Server based on 15 from BYOS to PAYG the values for the license information are as follows:

THE_CURRENT_ATTACHED_LICENSE=projects/suse-byos-cloud/global/licenses/sles-15-byos 
THE_NEW_LICENSE_TO_USE=projects/suse-cloud/global/licenses/sles-15

A closer look at the license string

As you can see from the license identifier used in the example above, licenses are scoped by GCP project, as indicated by the projects name in the license identifier. This is followed by the project name; for SUSE Linux Enterprise images for which the flexible license feature works and is enabled the following projects are of interest to you

• suse-byos-cloud
• suse-cloud
• suse-sap-cloud

These names are the names of the projects SUSE uses to publish our SUSE Linux Enterprise Server and SUSE Linux Enterprise Server for SAP applications PAYG and BYOS images, respectively. The project names are also part of the pint data, for example

pint google images --active --filter 'name~15-sp7,name\!byos,name\!sap,name~x86-64' --json

yields the following, at the time of this writing.

{  
    "images": [  
        {
            "changeinfo": "https://publiccloudimagechangeinfo.suse.com/google/sles-15-sp7-v20250619-x86-64/",
            "deletedon": "",
            "deprecatedon": "",
            "name": "sles-15-sp7-v20250619-x86-64",
            "project": "suse-cloud",
            "publishedon": "20250619",
            "replacementname": "",
            "state": "active"
        }
      ]
 }

This is a PAYG image, indicated by the missing BYOS moniker in the image name, and you can see the image is published from the suse-cloud project. This covers the first 2 parts of the license string. The next two parts are static and are always global and licenses. The last part of the license identifier is the name of the license, for these we have the following options:

• For SUSE Linux Enterprise Server – PAYG (SLES-PAYG)
  • sles-12
  • sles-15
• For SUSE Linux Enterprise Server – BYOS (SLES-BYOS)
  • sles-12-byos
  • sles-15-byos
• For SUSE Linux Enterprise Server For SAP application – PAYG (SLES-SAP-PAYG)
  • sles-sap-12
  • sles-sap-15
• For SUSE Linux Enterprise Server For SAP application – BYOS (SLES-SAP-BYOS)
  • sles-sap-12-byos
  • sles-sap-15-byos

With the above information you can now compose the appropriate license id to switch the billing model of your instances as you see fit.

And as a bit of future proofing, use 16 instead of 15 in the names given above after SLE 16 is released later this year.

Important is to remember that the switch can only take place when an instance is stopped. As mentioned, a license is associated with the root volume (“disk”) of your instance and operations on the “disk” are only possible when the instance is not running.

What are the supported model switches?

1.) You can replace any PAYG license of the same product with another PAYG license of the product that has a higher version number. Meaning if your instance started out as a SLES 11 instance and the inside of the instance has been upgraded to SLES 15 SP? you can now also update the license indicator by using

projects/suse-cloud/global/licenses/sles-11,projects/suse-cloud/global/licenses/sles-15

as the value for replace-license. Such a change has no effect on how your instance is charged, SLES 11, SLES 12, and SLES 15 carry the same up-charge over the GCE instance pricing. The same basic operation also works for SLES For SAP. And it also works for BYOS. Meaning within the same billing model and the same product you have complete freedom to switch as you see fit.

2.) You can switch from BYOS to PAYG and vice-versa within the same product family. For example

projects/suse-byos-cloud/global/licenses/sles-sap-12-byos,projects/suse-sap-cloud/global/licenses/sles-sap-15

as the value for replace-license will switch a SLES For SAP BYOS instance to a PAYG instance, at the same time indicating that the instance itself has been upgraded to SLES 15 For SAP at some point. The version indicators are there for historic reasons. In hindsight we should have just named those sles, sles-byos, sles-sap, sles-sap-byos, but we cannot undo the past. As such the version indicators are present and we’ll stick with the pattern going forward, i.e. we’ll have sles-16, sles-16-byos, sles-sap-16, and sles-sap-16-byos.

3.) You can now upgrade a SLES PAYG instance to SLES For SAP PAYG just like in the data center (thr process is different as outlined below.) This is a one way street, i.e. it only works from SLES to SLES For SAP and not the other way around. All commands executed as root.

First get the version appropriate SLES For SAP product package

wget --no-check-certificate https://104.196.61.109/SLES_SAP-release-15.7-150700.28.1.x86_64.rpm
wget --no-check-certificate https://104.196.61.109/SLES_SAP-release-15.6-150600.37.2.x86_64.rpm
wget --no-check-certificate https://104.196.61.109/SLES_SAP-release-15.5-150500.43.2.x86_64.rpm
wget --no-check-certificate https://104.196.61.109/SLES_SAP-release-15.4-150400.55.1.x86_64.rpm

Now you want to disconnect your running instance from the update infrastructure by first stopping the license watcher (more on this later) and then de-registering the instance

systemctl stop guestregister-lic-watcher.timer
registercloudguest --clean

Now that the system is no longer connected to the update infrastructure switch the product to SLES For SAP

Now it is time to stop the instance and apply the SLES For SAP licence, i.e. use

projects/suse-cloud/global/licenses/sles-15,projects/suse-sap-cloud/global/licenses/sles-sap-15

as the value for –replace-license in the previously shown command. Once this is set fire up your instance and it will register itself with the update infrastructure as SLES For SAP. That means longer life-cycles, integrated support between SAP, Google, and SUSE, access to HA packages, and a few other perks. You can run

zypper lr | grep -i sap

to verify that the switch worked as expected. Note that since you started with a SLES instance and switched it to SLES4SAP the installed software is still what we deliver with a SLES instance plus whatever you installed. There are differences in the image content between SLES and SLES4SAP images and depending on what you are running in the instance you may need to install additional software. One package, if your are running SAP workloads, is the google-cloud-sap-agent that you will need to install, this is required in order to get support.

zypper in google-cloud-sap-agent
systemctl enable google-cloud-sap-agent.service
systemctl start google-cloud-sap-agent.service

Also note that there is a 90-day lockout period, meaning the license cannot be switched for 90 day after an instance is started or for 90 days after a license switch has occurred. Meaning if you switch from one license to another, you are stuck with the new license for 90 days. In exceptional cases, if mistakes happened, please reach out through Google support and we will collectively try to help you to get into the state where you want to be.

The other half of the story

The above information handles the outside of the instance, (well the product switch explained above also covers the inside of the instance) i.e. the picture of the instance the GCE framework sees. However we also have to manage the inside of the instance. Inside the instance we need to pay attention to how the running software is maintained. When starting an instance from a PAYG image the instance will connect itself automatically to the SUSE update infrastructure running in GCE. For instances started from BYOS images a manual operation for registration is required since a registration key is necessary. The goal is to maintain such behavior when an instance is switched from PAYG to BYOS or vice versa. This is the job of the guestregister-lic-watcher systemd timer. The license watcher service sends instance data to to the update infrastructure every minute to check if the instance billing model has changed or not. If the instance billing model has changed from BYOS to PAYG the instance will be de-registered, freeing up one system from the used subscription during registration and then the instance will be connected to the update infrastructure. If the instance is switched from PAYG to BYOS the instance will get disconnected from the update infrastructure and is treated like an instance started form a BYOS image. This means the user needs to run registercloudguest -r $REGISTRATIONCODE to access repositories via the SUSE GCE update infrastructure or run SUSEConnect -r $REGISTRATIONCODE to connect the instance to the repositories provided by the SUSE CDN. In order to take advantage of this automation the instance must have the cloud-regionsrv-client-license-watcher package installed.

If your instance was started from a SLE 15 SP4 or later image with a timestamp greater or equal to 20250531 the package is already installed and the timer will be running. If you are not certain you can check with

systemctl status guestregister-lic-watcher.timer

If you get a message from systemctl that the unit could not be found and you are interested in automation that supports the flexible license feature you can install the package, which is provided by the Public Cloud Module and enable the timer as follows:

zypper in cloud-regionsrv-client-license-watcher
systemctl enable guestregister-lic-watcher.timer
systemctl start guestregister-lic-watcher.timer

And that’s all there is to it.

Before I let you go…..

There is one more piece of information you might find useful if you are interested in performing billing model changes, that is the image name used to start the running instance.

gcemetadata --query instance --image

And for those wanting to have a closer look at the commercial implications take a look at Optimize Google Cloud Spend with Flexible Licensing