Goal of this guide
This article puts SUSE platform into a practical context and explains the decisions that matter for a reliable implementation. By the end, you should know what to prepare, how to recognize a working state and what the next useful step is.
SLES 16: what is new?
SLES 16 is not just the next YaST-based server with a new logo. Agama, NetworkManager, SELinux, Cockpit, Btrfs/Snapper and a more modern operating model noticeably change the path from ISO to a production-ready server. This guide walks you through a complete installation step by step.
Tested environment / lab setup
The screenshots come from a real SLES 16 installation in an isolated KVM environment. Host names and addresses are neutralized; registration codes, credentials and internal infrastructure are not shown.
What you will have at the end
- an installed SLES 16 server with a stable base installation
- registered SUSE repositories through SUSE Customer Center or a suitable enterprise process
- an administrative user with sudo and a deliberate root/SSH model
- Btrfs as root filesystem with Snapper as the snapshot foundation
- NetworkManager instead of wicked as the networking baseline
- SELinux, firewalld, systemd and Cockpit as core operations components
- a first technical acceptance using SUSEConnect, zypper, SSH, Cockpit and Snapper
Prerequisites
You need suitable SUSE images, entitlements, DNS, NTP, storage, network access and administrative accounts. Registration and mirroring data stay out of screenshots, Git and public text.
1. Choose the installation medium
For a reproducible server installation, start with the official SLES 16 installation medium from SUSE Customer Center. In practice there are two common paths: an online/network medium for a smaller download with repository access during installation, or a larger full/offline medium for environments with limited internet access.
- Online ISO: useful when the VM has reliable internet access or access to an internal repository system during installation.
- Full ISO: useful when you want a more controlled or offline installation with registration afterwards.
- Production environments: document medium, version, checksum and source.
2. Verify the ISO
Verify the downloaded ISO before attaching it to a VM or installation workflow. The checksum must come from SUSE Customer Center or another official source.
sha256sum SLE-16.0-*.isocat SLE-16.0-*.iso.sha256sha256sum -c SLE-16.0-*.iso.sha256
Production runbooks should also state who downloaded the medium, where it is stored and when it should be replaced by a newer version.
3. Prepare VM or hardware
For a small server baseline, only modest resources are needed in a test. For real systems, size according to workload, I/O, backup window and support requirements. The important part is to deliberately define UEFI/BIOS, boot order, disk size and networking before the first boot.
qemu-system-x86_64 \ -enable-kvm \ -machine q35 \ -cpu host \ -smp 2 \ -m 4096 \ -drive file=sles16-server.qcow2,format=qcow2,if=virtio \ -cdrom SLE-16.0-Online-x86_64.install.iso \ -boot once=d \ -netdev user,id=n1,hostfwd=tcp::2222-:22,hostfwd=tcp::9090-:9090 \ -device virtio-net-pci,netdev=n1
The `-boot once=d` option matters: the VM boots from ISO once and then returns to the installed disk. This avoids booting back into the installer after the reboot.
4. Start into Agama
Select the regular installation entry in the boot menu and wait until Agama is reachable. If you work on the local console, use the displayed interface directly; on remote servers you can also use the browser URL shown by Agama. Continue only when the interface is stable and no network or certificate warning makes the installation ambiguous.
First check the target product in Agama. For this article the product is SUSE Linux Enterprise Server 16. If several products or modules are offered, select only what fits your later support and repository model.
After boot, the SLES 16 installer starts Agama. Agama is web-based and guides you through the installation through individual sections. You do not have to click through linearly: the left navigation shows which areas still need attention.
5. Read the overview, do not skip it
The overview is not just a start screen; it is your ongoing installation control. Every area that still needs attention must be completed before installation starts. Use it as a checklist: product, registration, language, keyboard, time zone, networking, storage, users and software must fit together.
The overview is the most important control page. It shows whether registration, localization, storage, networking and user creation are complete. If Agama warns here, fix the cause before starting installation.
6. Understand registration correctly
When the registration code is accepted, the installation is not automatically complete. Agama must also be able to assign the matching products and repositories. Verify that the expected SLES 16 repositories are available and that the network connection remains stable. Without working repositories you may install a system, but not a maintainable enterprise Linux server.
With SUSE, separate two concepts: the subscription or entitlement may already be activated in SUSE Customer Center. The individual SLES server still needs to be registered against that entitlement using a valid registration code or your enterprise registration process.
- Check the host name before registration because it can later be visible in SCC.
- Select registration server: typically SUSE Customer Center or an internal RMT/manager process.
- Enter the registration code only in the protected dialog.
- Use the optional email field only if your organization wants it.
- After successful registration, matching repositories must be available.
7. Set language, keyboard, time and host name
Set the time zone according to how the server will be operated, monitored and audited. For Austria this is typically Europe/Vienna. The host name should be the final FQDN or at least the later target name, not a temporary installer name. This reduces later work for certificates, monitoring, logs and Manager onboarding.
Localization may sound minor, but it matters operationally. Keyboard layout, language, time zone and host name affect admin access, logs, timestamps, monitoring and certificates. Set the final host name before registration and before the first production boot.
Recommended decision before installation:
- Host name: sles16.example.test
- Time zone: Europe/Vienna
- Keyboard: de or us, matching the administrator team
- Language: according to operations standard, often English for server logs and support
8. Check networking
Check address, gateway, DNS and name resolution in the installer. If you use DHCP, reserve the address. If you configure networking statically, document IP address, netmask, gateway, DNS servers and search domain in the operations runbook. The server must reach SUSE Customer Center, RMT or SUSE Multi-Linux Manager; otherwise registration and updates fail later.
SLES 16 uses NetworkManager. In the installer, check whether the primary interface receives the expected address, route and DNS resolution. For production systems, use static addressing or clean DHCP reservations with a documented DNS zone.
- FQDN must resolve the same way before and after reboot.
- NTP, SCC/RMT, package sources, SSH and Cockpit must be reachable.
- Open firewall rules for SSH and Cockpit deliberately.
9. Define storage deliberately
Accept the storage proposal only when it fits the server role. Btrfs on root with Snapper is useful for operating system rollbacks. Databases, application data, logs or large payload data often belong on separate volumes so snapshots, backups and performance do not interfere with each other. Before installation starts, decide clearly what is system data and what is application data.
The default path in the screenshot creates a root partition with Btrfs and a swap partition. For many SLES servers this is a sensible starting point because Btrfs and Snapper support rollbacks. For databases, large payload data or special workloads, plan additional filesystems separately.
Typical production decision:
- /: Btrfs with Snapper
- /var: evaluate separately depending on workload
- swap: according to RAM, hibernation requirements and operations standard
- data: own volumes or disks, aligned with backup and restore design
10. Create administrator and SSH model
Create the first user so you can work after reboot without sharing a root password. In production this means a personal admin account, sudo, SSH keys, disabled or clearly limited root SSH access and documented emergency access. Before starting installation, verify that you can actually use this access after reboot.
Before installation, Agama requires either a first user, a root password or an SSH key. For production systems, a personal admin user with sudo, SSH key and a documented break-glass root model is usually a better foundation than a shared root login.
11. Keep software selection lean
For a base server, less is better. Do not install a graphical desktop or roles you do not need. Everything else should later be added through documented packages, roles, Ansible, Salt or SUSE Multi-Linux Manager. This keeps the first baseline traceable and reproducible.
Install only what you need for the server role. A lean base is easier to patch, harden, secure and later manage in SUSE Multi-Linux Manager. Cockpit is helpful for day-2 administration, but it does not replace automated configuration.
12. Review and start installation
The final Agama summary is the last point where you can correct safely. Read it like a change approval: correct product, completed registration, correct storage target, user present, network reachable, software selection deliberate. Only then start the installation and wait until Agama reports completion.
Before clicking “Install”, review product, registration, host name, networking, storage, users and software. This moment is the installation acceptance. Start installation only when the overview matches your target state.
13. Reboot and first login
After reboot, sign in locally or through SSH and verify that the configured user can use sudo. Then check host name, time, networking, repositories and services. Only when these baseline checks pass is the server ready for hardening, monitoring, backup or onboarding into SUSE Multi-Linux Manager.
After installation completes, the system boots from the installed disk. Remove the ISO or use a boot configuration that does not boot from the installation media again. Then check console, SSH and Cockpit.
ssh -p 2222 forgeone@sles16.example.testhostnamectlcat /etc/os-releasesystemctl is-system-running
14. Verify registration, repositories and updates
A successful installation is complete only when registration and repositories work. Therefore, do not only check whether the server boots; verify that it receives updates.
sudo SUSEConnect --status-textsudo zypper lr -usudo zypper refreshsudo zypper patch --dry-runsudo zypper patch
If `SUSEConnect --status-text` does not show clean registration or `zypper refresh` fails, the server is not accepted yet. Clarify registration, DNS, proxy, certificates and repository access before installing workloads.
15. Verify NetworkManager instead of wicked
The move to NetworkManager is one of the most important operational differences for many SLES administrators. Use `nmcli` and Cockpit to verify the active connection. Configuration management should later set the same facts reproducibly.
systemctl is-active NetworkManagernmcli device statusnmcli connection show
16. Accept SELinux, firewalld, SSH and Cockpit
SLES 16 moves closer to familiar Enterprise Linux components. Verify SELinux, firewalld, SSH and Cockpit right after the first update. This shows early whether the security baseline and remote administration fit together.
getenforce || sestatussudo firewall-cmd --statesudo firewall-cmd --list-allsystemctl status sshd --no-pagersystemctl status cockpit.socket --no-pager
17. Verify Btrfs and Snapper
Btrfs and Snapper are important building blocks for rollback scenarios around updates. This does not replace backups, but helps with operating system changes, package updates and quick technical correction.
findmnt /sudo snapper listsudo snapper create --description "post-install validation"sudo snapper list
18. Final acceptance check
- ISO source and checksum documented
- Host name, DNS, time zone and networking verified
- SLES 16 registered and repositories available
- Updates and patches tested successfully
- Admin user, sudo and SSH defined deliberately
- SELinux, firewalld, Cockpit and systemd verified
- Btrfs/Snapper functional
- Server ready for baseline hardening, monitoring, backup and onboarding into SUSE Multi-Linux Manager
Operations and validation
A successful installation alone is not enough for production operations. Validate services, logs, networking, login, updates, backup and recovery so that the state is repeatable and understandable for other administrators.
Production checklist
- Goal, scope and ownership are documented.
- DNS, TLS, networking, accounts and permissions are validated.
- The installation or change is verified with UI and CLI signals.
- Backup, monitoring, updates and rollback are planned before production use.
- Licensing, support paths and professional services are planned for operations.
Next step: central management
A cleanly installed SLES 16 server is the foundation. The next step is SUSE Multi-Linux Manager 5.2: installation, Product Catalog, channel sync and then onboarding mixed Linux clients.
Evidence from the tested manager environment
The following sections do more than list commands. They show real state from the tested SUSE Multi-Linux Manager 5.2 environment: registered clients, channel assignment, package and patch counts, scheduled actions and the current audit state. access data, registration codes and internal infrastructure are deliberately not visible.
- Install SLES 16 for production - this article
- Install SUSE Multi-Linux Manager 5.2 for production
- Onboard first Linux clients for production
- Build production patch and lifecycle management
- Manage mixed Linux estates in production
- Use OpenSCAP, compliance and audit in production
- Build proxies for sites and distributed Linux estates
- Integrate SSO with Keycloak, SAML and MFA
- Use Ansible alongside Salt in production
- Build reporting, inventory and subscription audit
- Operate and harden the manager in production
SUSE series: the useful order
This article is the entry point into the series. SUSE Multi-Linux Manager and mixed Linux operations follow afterwards. The articles are planned so one additional part goes online each day.
- Install SLES 16 for production - this article.
- Install SUSE Multi-Linux Manager 5.2 for production.
- Onboard first Linux clients for production.
- Patch and lifecycle management with SUSE Multi-Linux Manager.
- Manage mixed Linux: SLES, SL Micro, Debian, Ubuntu, Rocky, Alma and Oracle Linux.
Complete SUSE series
This foundation article starts the SUSE series. SUSE Multi-Linux Manager installation and operations, client onboarding, patch management, mixed Linux, OpenSCAP, reporting and hardening build on it.
