SUSE Manager 3.0 arrives in the Public Cloud, at long last | SUSE Communities

SUSE Manager 3.0 arrives in the Public Cloud, at long last


SUSE Manager 3.0 Server and SUSE Manager 3.0 Proxy images are now available in Amazon EC2, Google Compute Engine, and in Microsoft Azure.

But of course I cannot just leave it at this announcement as that would make for a rather short and boring blog post. Thus, lets dive into the details, just a little bit. As with the SUSE Manager 2.1 image releases  the images for SUSE Manager Server and SUSE Manager Proxy for version 3.0 are BYOS (Bring Your Own Subscription) images, which means an instance started from these images needs to be registered with the SUSE Customer Center (SCC).

Starting at the beginning one has to find the images to launch an instance first . This can be accomplished via pint

pint $FRAMEWORK images –region REGION_NAME –active –filter ‘name~manager,name~3’

will do the trick with $FRAMEWORK replaced by one of amazon, google, or microsoft and REGION_NAME set to the appropriate region. In Google Compute Engine all images are global and thus the “–region REGION_NAME” can be dropped. Alternatively the images can be found through the web console of your favorite Public Cloud Platform.


The BYOS images are published in the so called “General Catalog” which is accessible via the “Community AMIs” tab to the left in the “Quick Launch” screen that is presented once you click the “Launch Instance” button. In the search box at the top simply search for “manager-server” or “manager-proxy”.


The SUSE Manager images will only be visible in your account in the web console if you subscribe to the “suse-byos-cloud [at] googlegroups [dot] com” mailing list. This works by sending a message from your Google account to “suse-byos-cloud+subscribe [at] googlegroups [dot] com”. Once subscribed you can see the images in your image list in the web console.

Update 2017-05-26: The google group “suse-byos-cloud at googlegroups dot com” has been deleted and BYOS image in GCE are public and can be instantiated just like other public images.


Within Azure two portals exist, one is the ARM (Azure Resource Manager) based portal and the other is the Classic (ASM based) portal. The image is only available in the ARM based portal and can be found in the Marketplace. Marketplace is taking the spot of VM-Depot where the Manager 2.1 images were found.

Running SUSE Manager 3

Once you have the image you are interested in and you are ready to launch consider the instance size you are using. As with the SUSE Manager 2.1 release we have attempted to make the Manager installation be as close to a physical installation as possible. Thus the SUSE Manager 3 documentation applies as far as resource considerations are concerned. Of course when you use the provided images you get to skip the installation step. Any cloud specific documentation can be found in the “SUSE Manager in the Public Cloud”  document.

Keep in mind that you need to configure your network such that your manager instance is NOT accessible from the Internet at large. Once you have one SUSE Manager server registered with SCC and up and running there are a number of options to manage client systems across the world, various Public Cloud Frameworks, and your data center. I will highlight one particular usage model here, others are left to your imagination.

The entitlement model for SUSE Manager is a 3 tier model, one entitlement for SUSE Manager, a bunch of SUSE Lifecycle Management entitlements, and a corresponding number of SUSE Linux Enterprise Server entitlements. Thus in a pure BYOS setup all three entitlements need to be obtained from SUSE and things look pretty much the same as in a traditional data center. But this is the cloud and thus things need to be a bit more interesting. In the Public Cloud it is possible to replace the direct purchase of a SUSE Linux Enterprise Server entitlements with the use of on demand images published by SUSE. Using on demand images has the advantage that you never have to worry whether or not you are current on your SLES subscriptions.

On demand images do have some “special sauce” that registers an instance with the SUSE operated update infrastructure. However, this registration would get in the way of an instance managed by SUSE Manager as it provides a way around the repositories and packages managed by SUSE Manager. Therefore we want to get rid of the “special sauce” and the setup and configuration for the auto registration for an instance intended to join the SUSE Manager machine pool. So before joining an on demand instance to SUSE Manager do the following:

zypper rm cloud-regionsrv-client

On Amazon EC2

zypper rm regionServiceClientConfigEC2 regionServiceCertsEC2

On Google Compute Engine

zypper rm cloud-regionsrv-client-plugin-gce regionServiceClientConfigGCE regionServiceCertsGCE

On Microsoft Azure

zypper rm regionServiceClientConfigAzure regionServiceCertsAzure

Than edit “/etc/hosts” and remove the entry that contains “”. Last but not least remove the SUSEConnect configuration file.

rm /etc/SUSEConnect

These steps by the way are also outlined in the SUSE Manager documentation. Now you can join the instance to your SUSE Manager instance. Be aware of the duplicate machine ID issue. All instances launched from the same image have the same machine ID and thus you need to fix this, also in the documentation. We are working on addressing this and I expect that SLES 12 SP3 images will have this resolved, i.e. every instance will have a different machine ID even if started from the same image. We also have created a special bootstrap repo that will make joining an instance to your SUSE Manager a bit easier, again see the documentation.

So what can you do with all of this wonderful stuff. Well first off SUSE Manager 3.0 comes with Salt Stack integration, see the SUSE Manager documentation, oh and by the way the images were just built and thus you actually are getting SUSE Manager 3.0.3. With Salt Stack you get some configuration management goodies with SUSE Manager, a great new feature in SUSE Manager 3.0.

With some clever network magic you can, using your own data center network as a “hub” run a SUSE Manager proxy instance in every region of every cloud provider and have one SUSE Manager Server instance feed all of those proxies. Then any instance you may run in any region get updates locally from that proxy, i.e. super fast updates, and I mean it, super fast. That of course is just one use case, the sky is the limit.

With the big hurdle of 2.1 to 3.0 behind us we’ll do better with the next release of SUSE Manager, i.e. image release will be closer to FCS, whenever that may be and whatever it may be called. But let me just say it will not be called 4.0

Update 2017-02-07:

One thing I neglected to point out is that the image is based on SLES 12 SP1. At the time of build and release SUSE Manager 3.0 Server and Proxy were not supported to run on SLES 12 SP2. As of today this has changed and SUSE Manager Server 3.0 Server & Proxy are now fully supported to run on SLES 12 SP2. Thus once you launch and instance and have it registered you can migrate the instance from SLES 12 SP1 to SLES 12 SP2 using steps outlined in Some goodies for the upcoming holidays, SLES 12 SP2 in the Public Cloud.

(Visited 1 times, 1 visits today)


  • dvosburg says:

    Great news, Robert! Lots of great use cases for SUSE Manager 3 in the public cloud.

    Perhaps you can give suggested instance sizing for a typical server, as this may differ slightly from on premise deployments.

    Thanks for the update – I will use it!

    • rjschwei says:

      From a sizing perspective we have not noticed any difference in behavior that would justify using different recommendations than documented in the SUSE Manager Documentation.

  • Leave a Reply

    Your email address will not be published.