Upgrades for Azure Hybrid Benefit

A while back in cooperation with the Azure team we enabled Azure Hybrid Benefit for SUSE Linux Enterprise images. In the first incarnation it was possible to switch a SUSE Linux Enterprise Server or a SUSE Linux Enterprise Server For SAP Applications instance from PAYG (on-demand) to BYOS (Bring Your Own Subscription). Such a switch helps when the need for LTSS (Long Term Service Pack Support) arises or if one wants to re-use entitlements that are no longer needed in the data center.

As time passed many customers also asked for a switch in the other direction, i.e. from BYOS to PAYG. One primary reason for such a switch is the ability to build custom images and then have them become PAYG instances without starting from a SUSE published image. A switch from BYOS to PAYG is possible with the latest upgrades to the Azure Hybrid Benefit  implementation.

What you need

In your custom image or running instance you will need at least version 10.0.3 of the cloud-regionsrv-client package and you will need to install the net new cloud-regionsrv-client-addon-azure package, version 1.0.4 or greater. In addition the cloud-regionsrv-client-plugin-azure, regionServiceClientConfigAzure, and python3-azuremetadata packages need to be installed. Last but not least you will need to enable a systemd timer

systemctl enable regionsrv-enabler-azure.timer

that’s it for the pre-requisites.

If you have an instance, PAYG or BYOS, running from an image released on or after 20220505 (SLES or SLES For SAP) these conditions are already met. For running instances from images prior to 20220505 some or all of these packages will be missing and need to be installed.

For running PAYG instances

An update will enable a more convenient way, it is now automated, to switch from PAYG to BYOS than previously, a

zypper up

followed by

zypper in cloud-regionsrv-client-addon-azure

plus the timer enablement, see above, will do the trick.

For running BYOS instances

For instances from images prior to 20220505 you need to install everything from scratch

zypper in cloud-regionsrv-client cloud-regionsrv-client-addon-azure cloud-regionsrv-client-plugin-azure regionServiceClientConfigAzure python3-azuremetadata

then enable the timer and you are all set. This makes the assumption that your BYOS instance is registered to a repository server, SCC, RMT or managed via SUMa and the Public Cloud Module is enabled. For SUMa managed systems “zypper in” is of course a push operation from SUMa.

Azure integration

For convenience there is also an extension, AHBForSLES, that handles the installation of the necessary packages.

az vm extension set -n AHBForSLES –publisher SUSE.AzureHybridBenefit –vm-name myVMName –resource-group myResourceGroup

will install the extension in your instance. The extension handles the installation of packages and as such is not needed for instances launched from images with a date stamp of 20220505 or later. As for running BYOS instances the assumption is that your instance is registered to SCC or RMT. If your system is managed with SUMa the extension is not useful. More about the extension and the topic when you are not connected to SCC with your BYOS instance below.

How to use the new feature?

You need a reasonably up to date version of the azure-cli, this does not have to be in the instance. Usage from the command line is straight forward, use the

az vm update –license-type

command to modify the license setting of an instance. Supported values are

SLES_BYOS -> Switches a PAYG instance to a BYOS instance
SLES_HPC, SLES_SAP, SLES_STANDARD -> Switches a BYOS instance to a PAYG instance

As you can see the switching from BYOS to PAYG has multiple values and this is important as these values correlate to different pricing. Also it is important with respect to getting updates. The value you use must correspond to the product in the instance. For example, if an instance started from a SLES For SAP BYOS image gets set to the SLES license-type, i.e.

az vm update –license-type SLES_STANDARD …..

registration to the update infrastructure will fail as the product in the instance, SLES For SAP, does not match the license type setting, SLES_STANDARD. Meaning for a SLES For SAP instance the license-type has to be set to SLES_SAP, i.e.

az vm update –license-type SLES_SAP

Talking about registration with the update infrastructure. This is what the timer handles. The new azure-enabler service watches the metadata of the running VM and when changes to the license type are made makes the appropriate changes to the repository set up. This timer is built in and enabled for images published after 20220505 which is why instances from those images do not need the extension or additional packages installed.

When an instance is switched from BYOS to PAYG the azure-enabler service will automatically de-register the system from SCC (SUSE Customer Center) such that your systems are properly counted and then register the system with the update infrastructure in Azure. This process does not effect custom repositories, they will get preserved. In the opposite direction when a PAYG instance gets switched to BYOS via

az vm update –license-type SLES_BYOS

the azure-enabler service will disconnect the instance from the update infrastructure such that you can use your own registration code to access updates. You can still get your updates for the newly turned BYOS instance from the update infrastructure if you want. If you care to look at the details about what the azure-enable code does, it is part of the cloud-regionsrv-client project.

If you use your own RMT server as intermediary for SCC you will need to ensure that your system count is correct. Neither the implementation in the azure-enabler nor in the extension account for this scenario for various reasons.

The AHBForSLES extension mentioned previously is for convenience. The extension will ensure that the necessary package versions are installed in an instance and will enable the azure-enabler timer. Some caveats exist for the use of the extension.

The extension itself will fall back on a so called “unrestricted repository” if the system is not registered. The “unrestricted repository” contains a select number of packages that are maintained and made available without registration. This allows a large set of instances to be converted from BYOS to PAYG without being connected to SCC. That said there will also be many cases where the content of the unrestricted repo will not be sufficient. For those cases a connection to SCC is needed. Preferably you will do the switch from BYOS to PAYG before your SCC entitelment expires and before you disconnect the BYOS instance manually from SCC. This ensures that all the packages are available to you and provides the tested path to success of the BYOS to PAYG conversion.

We cannot cover all corner cases for all running instances that may be targeted for such a conversion. In cases when the unrestricted repo does not contain all the packages needed it is reasonably straight forward to set up a connection to SCC. Use the SUSE Products page to select the product you wish to convert from BYOS to PAYG (SLES or SLES For SAP).

Follow the “Download” link. Select the Service Pack and Product version (12 or 15) from the top of the page and then select the “Download” link for the “.iso” file. On the following form provide your information and check the “60-day Trial” license box. You will receive a registration code that provides access to SCC for 60 days. Note you can only do this once. If you have many systems that are targeted for switching make sure your maintenance window for all systems falls within the 60 day period.

Once you have the registration code connect the instance to SCC with the SUSEConnect command and your 60 day trial code.

SUSEConnect -r $THE_TRIAL_REGISTRATION_CODE -e $YOUR_E_MAIL

Once the system is registered the extension will handle the rest.

What does this mean for other images/products?

The SUSE Manager, Proxy and Server, images do not have the necessary packages pre-installed. The reason for this is that the underlying OS instance for SUMa is SUSE Linux Enterprise Server and as such it does not include the necessary SUSE Manager Life-cycle Management entitelment, unlike SLES For SAP. Therefore a switch to PAYG would make it too accident prone to be out of compliance. If you have the necessary Life-cycle Management entitelment, simply enroll the underlying OS into your SUMa infrastructure, push the packages listed above and switch the instance to PAYG.

The CHOST images are flavor builds of SLES. However these images do not contain any convenience packages. That said it is easy to install the packages listed above and then switch the instances to be PAYG.

SLE-Micro is a separate product and AHB does not apply. Further SLE-Micro is not yet offered as a PAYG flavor.

Why SLES_STANDARD and not SLES?

This is on the to do list and SLES_STANDRAD will eventually change to SLES. The name was chosen to match the image names, we publish “standard” images and “basic” images. The images in pint that are labeled as “basic”, for example suse-sles-15-sp3-basic-v20220427-x86_64-gen2 do not have support while images without “-basic” in the name, i.e. standard images include support. For AHB (Azure Hybrid Benefit) one can only switch to PAYG by also opting into support which brought about the SLES_STANDARD name for the license type. However, given that there is no name association to the image name this nuance is easily lost and as such naming the license type SLES just makes more sense.

When the change from SLES_STANDARD to SLES happens the azure cli will provide appropriate feedback and this will be easy to spot.

SUSE Manager (SUMa) systems

Systems that are managed by SUSE Manager can also be switched from BYOS to PAYG. Note, as mentioned previously for SLES you need the appropriate number of SUSE Life-cycle Manager entitelements. For SLES For SAP instances the entitelemnt is part of the SLES For SAP on-demand pricing. When you switch a SUMa managed instance from BYOS to PAYG you want to first push the necessary packages for the switch from SUMa to the system, see above. Then drop the system from SUMa, switch the instance from BYOS to PAYG, wait until the timer code does it’s magic, i.e. you have repositories configured from the update infrastructure, grep susecloud /etc/hosts, will return a value and then re-enroll the system into SUMa. This ensures that you remain in compliance and do not double count any systems that are PAYG but were previously BYOS against your total system entitelemnts.