Installing SUSE Linux Enterprise Server 16: From ISO to a Production-Ready Linux Server

What This Guide Covers

This guide builds SUSE Linux Enterprise Server 16 from a real ISO in a KVM lab. It is intentionally practical: verify the ISO, start the VM, use Agama, register the system, create an admin user, and validate storage, networking, SELinux, firewall, Cockpit and updates. The goal is not a marketing overview, but a reproducible installation path for administrators.

The installation was validated with the SLES 16 online installation medium in a disposable VM. The lab registration uses a test subscription. The important distinction is this: a subscription can already be activated, while an individual SLES system still needs to be registered against that entitlement. Registration only passes when `SUSEConnect --status-text` shows the installed system as registered and repositories are usable.

SLES 16: More than a new installer

SLES 16 modernizes several long-standing SUSE administration concepts at the same time. Agama is only the most visible entry point. Operationally, the model moves away from a strongly YaST-centered mindset toward installation through Agama, interactive day-2 administration through Cockpit and CLI, reproducible configuration through Ansible, and fleet/lifecycle management through SUSE Multi-Linux Manager where that fits the organization.

This does not make SLES 16 a different distribution, and it does not make it interchangeable with RHEL. But many day-to-day tools are more familiar to modern Enterprise Linux administrators: `systemctl`, `journalctl`, `nmcli`, `firewall-cmd`, SELinux, Cockpit, KVM and Ansible. The learning curve therefore moves more strongly toward the truly SUSE-specific areas: `zypper`, SUSEConnect, SCC/RMT, Btrfs/Snapper, Agama, and SUSE lifecycle and repository models.

Lab Setup

The lab is small enough for a laptop or build host and large enough to validate SLES 16 realistically. Production systems need different sizing and controls, especially for storage, networking, backup, monitoring and lifecycle processes.

vCPU:      2
RAM:       4 GiB
Disk:      40 GiB qcow2
Hostname:  sles16.example.test
Domain:    example.test
Network:   NAT for lab validation
Firmware:  UEFI recommended for production

SLES-16.0-Online-x86_64-QU0.install.iso

Verify the ISO

Before booting the installer, verify the ISO in a traceable way. The local file was `SLES-16.0-Online-x86_64-QU0.install.iso` with a size of 661 MB. The SHA-256 checksum is recorded in the lab report.

ls -lh SLES-16.0-Online-x86_64-QU0.install.iso
sha256sum SLES-16.0-Online-x86_64-QU0.install.iso
isoinfo -d -i SLES-16.0-Online-x86_64-QU0.install.iso | sed -n '1,35p'

For production builds, also document the official download or mirror process. If you use a precisely named build such as a quarterly update medium, make clear which medium was tested and whether a later build intentionally differs.

Start the VM

The simplest path is a normal ISO boot with UEFI. The following example uses plain QEMU. In production-like environments, `virt-install` with libvirt is often more convenient, but the technical parameters remain comparable: 2 vCPU, 4 GiB RAM, 40 GiB disk, virtio storage and virtio networking.

qemu-img create -f qcow2 sles16.qcow2 40G

qemu-system-x86_64 \
  -machine q35,accel=kvm \
  -cpu host \
  -smp 2 \
  -m 4096 \
  -drive file=sles16.qcow2,if=virtio,format=qcow2 \
  -cdrom SLES-16.0-Online-x86_64-QU0.install.iso \
  -boot d \
  -nic user,model=virtio-net-pci,hostfwd=tcp:127.0.0.1:2222-:22

If the bootloader does not continue cleanly in a lab, Agama can also be booted directly through kernel and initrd. That is a lab workaround, not a requirement for a normal installation. For production installations, prefer a clean UEFI boot path.

Install with Agama

SLES 16 uses Agama as the modern installer. Agama is not simply YaST with a new interface; it is an installation and provisioning tool. In the browser you configure product, registration, language, keyboard, timezone, networking, software selection, storage and users. Set the hostname before registration so system identity, logs and subscription status stay clear.

The architectural model is deliberately separated: Agama installs and provisions, Cockpit supports interactive day-2 administration, the CLI remains essential for direct troubleshooting and operations, Ansible describes reproducible configuration, and SUSE Multi-Linux Manager handles fleet and lifecycle tasks when many systems need long-term management. Agama therefore does not replace every former YaST function.

• Product: select SUSE Linux Enterprise Server 16.0.

• Hostname: set `sles16.example.test`.

• Timezone: choose the operating timezone; the lab used `Europe/Vienna`.

• Software: explicitly enable Cockpit and SELinux.

• Storage: use Btrfs for `/`, swap and Snapper snapshots.

• Users: create the first admin user; root SSH password login is not the normal operating model.

A practical detail matters: if the software selection is reduced too aggressively, expected security components can be missing. In the lab, SELinux only became fully active after explicitly selecting the SELinux pattern. If you harden SLES 16 deliberately, verify not only the UI selection, but also kernel parameters, mounts, packages and `getenforce` after installation.

Understand Registration Correctly

Agama registration binds the installed system to an existing SUSE entitlement. A message that a subscription is already activated does not automatically mean that this VM is registered. Subscription activation and system registration are two different steps.

After installation, verify the system registration. Documentation and screenshots must never expose registration codes. For automation and runbooks, place them in secret stores or short-lived secret files with restrictive permissions, not in Git, screenshots, logs or CMS content.

First Boot

After reboot, the console should show the configured hostname and web console URLs. Then check the clean base state before changing packages, firewall rules or services.

cat /etc/os-release
uname -r
hostnamectl
systemctl --failed
ip addr show
ip route
nmcli connection show --active
timedatectl

In the validated lab, SLES 16.0 ran kernel 6.12, the hostname was `sles16.example.test`, NetworkManager was active and `systemctl --failed` showed no failed units. That is the minimum baseline before considering the installation clean. For RHEL, Rocky, AlmaLinux and Fedora administrators, this first diagnostic block feels familiar: systemd, the journal, NetworkManager and firewalld are not exotic SUSE-only paths.

NetworkManager Instead of wicked

Networking is one of the most important transitions for existing SLES administrators. SLES 15 could use wicked and NetworkManager; SLES 16 consolidates on NetworkManager. Scripts, runbooks and automation that expect wicked files or wicked commands therefore need review and adjustment.

The practical mindset changes: instead of “check wicked configuration,” you look at devices, connections and active profiles. Names differ between systems and installer choices, so the commands below intentionally use a synthetic connection name.

nmcli device status
nmcli connection show
nmcli connection show --active

sudo nmcli connection modify "Wired Connection" \
  ipv4.method manual \
  ipv4.addresses 192.0.2.20/24 \
  ipv4.gateway 192.0.2.1 \
  ipv4.dns "192.0.2.53 192.0.2.54"
sudo nmcli connection up "Wired Connection"

For administrators from the RHEL family, this is familiar: NetworkManager and `nmcli` have long been part of daily operations there. The distributions are still different. The tools are familiar; package management, registration, lifecycle and support model remain SUSE-specific.

Check Storage, Btrfs and Snapper

SLES continues to rely strongly on Btrfs and Snapper. That may be unfamiliar to administrators from RHEL environments, but it is important for SLES: package changes create snapshots, rollback scenarios become visible, and subvolumes separate areas such as `/home`, `/var`, `/opt` or `/srv`.

findmnt /
findmnt /tmp
lsblk -f
df -h
sudo btrfs subvolume list /
sudo snapper list

For SLES 15 administrators, Btrfs is familiar, but SLES 16 changes other operational habits. YaST is no longer the central installation and administration path; Agama, Cockpit, CLI and automation take over the relevant tasks.

From AppArmor to SELinux

SELinux is one of the biggest SLES 16 stories. Previous SLES generations were strongly associated with AppArmor. SLES 16 removes AppArmor and uses SELinux with policies covering a large part of the system. On a correctly configured SLES 16 system, SELinux should be active and normally run in enforcing mode.

This changes security troubleshooting and runbooks. Existing AppArmor assumptions cannot simply be carried over: denials, labels, contexts and policies are inspected and evaluated differently. RHEL administrators already know the basic model, but the concrete policy and package environment remains SUSE-specific.

getenforce
sestatus
sudo systemctl status firewalld --no-pager
sudo firewall-cmd --list-all
sudo nft list ruleset | sed -n '1,120p'

In the lab, SELinux ran in enforcing mode. firewalld was active, and `ssh` and `cockpit` were allowed. nftables was managed through firewalld. Production systems should define zones, sources, services and management access much more strictly.

getenforce
sestatus
sudo journalctl -t setroubleshoot --since "30 minutes ago"
sudo ausearch -m AVC,USER_AVC -ts recent

Do not solve SELinux problems by permanently disabling SELinux. The robust workflow is: observe the service problem, inspect denials in audit or journal data, understand the context or policy, correct configuration or policy, and verify again. That workflow separates production-grade hardening from a short-term workaround.

Check SUSEConnect, Products and Repositories

After the first boot, verify whether the system is really registered and knows the expected product and update repositories. This output can contain sensitive repository URLs and registration metadata. Do not paste it unredacted into tickets, screenshots or blog articles.

SUSEConnect --status-text
zypper products -i
zypper repos --uri
zypper patterns --installed-only

In the validated lab, SLES 16.0 was registered as the installed base product. Update repositories were usable. Optional external repositories such as NVIDIA or CUDA were visible but disabled. That is a good state for a lean server lab.

Test Updates and Patches

A freshly installed system is only truly assessable after a patch test. `zypper patch-check` shows what applies. `zypper patch` installs non-interactive patches. Interactive patches must be read deliberately and handled with the right option or maintenance window.

sudo zypper refresh
sudo zypper patch-check
sudo zypper list-patches
sudo zypper patch
sudo zypper patch-check

In the lab, non-interactive patches installed successfully. One interactive security patch remained open by design for manual decision. That is not an installation error; it shows why patch processes must distinguish standard patches from interactive changes.

Cockpit as Admin Interface

Cockpit is the web-based entry point for many SLES 16 day-2 tasks. It uses existing system APIs and is useful for overview, services, logs, storage, networking, SELinux and quick operational checks. For RHEL administrators Cockpit is familiar as well, so a freshly installed SLES 16 system can feel more accessible in daily operations than older SUSE installations.

Cockpit replaces neither CLI nor automation. It is the interactive layer for individual systems. Repeatable configuration belongs in Ansible or an appropriate fleet tool; package, repository and lifecycle decisions remain controlled through `zypper`, SUSEConnect, SCC/RMT and SUSE processes.

https://sles16.example.test:9090/

sudo systemctl enable --now cockpit.socket
systemctl status cockpit.socket --no-pager
curl -k -I https://127.0.0.1:9090/

Automatable Agama Installation

Agama is not limited to interactive use. For repeatable labs and later standardization, a JSON or Jsonnet based configuration can be loaded and validated. The following example is deliberately redacted and contains placeholders for secrets only.

{
  "product": {
    "id": "SLES",
    "registrationCode": "<REGISTRATION-CODE>",
    "registrationEmail": "<OPTIONAL-EMAIL>"
  },
  "localization": {
    "language": "en_US.UTF-8",
    "keyboard": "us",
    "timezone": "Europe/Vienna"
  },
  "network": {
    "hostname": "sles16.example.test"
  },
  "software": {
    "patterns": ["cockpit", "selinux"],
    "packages": ["vim", "curl", "policycoreutils", "selinux-tools"]
  },
  "users": {
    "root": {
      "sshPublicKey": "<ADMIN-SSH-PUBLIC-KEY>"
    },
    "users": [
      {
        "userName": "forgeone",
        "fullName": "ForgeOne Lab Admin",
        "hashedPassword": "<HASHED-LAB-PASSWORD>"
      }
    ]
  }
}

agama config validate /run/agama/profile.json
agama config load /run/agama/profile.json
agama install
agama monitor
agama finish

In the lab, the profile was validated and loaded in the live installer environment, then installed with `agama install`. Registration code and temporary passwords were used only short-lived, redacted locally and removed after completion. CI/CD-like workflows must connect this step to a secret store.

What Feels Different for RHEL Admins

SLES 16 uses several core components that administrators from modern Enterprise Linux environments already know. For RHEL administrators, SELinux and NetworkManager no longer represent a change in the basic operating model when moving to a current SLES system. The distributions remain different, but day-to-day building blocks overlap more strongly.

This explicitly does not mean that SLES 16 and RHEL are interchangeable distributions. What becomes easier is the administrator’s mental transition: an experienced Enterprise Linux engineer does not need to relearn SELinux fundamentals, `nmcli`, `systemctl`, `journalctl`, `firewall-cmd`, nftables concepts, Cockpit, KVM and Ansible. The real learning curve is `zypper`, SUSEConnect, SCC/RMT, Btrfs/Snapper, Agama, and the SUSE lifecycle, repository and support model.

What Changes for SLES 15 Admins

SLES 15 administrators do not need to relearn Linux for SLES 16, but they should take the platform changes seriously. Agama replaces the classic installer path, YaST is no longer the central administration anchor, NetworkManager is the path forward, SELinux replaces AppArmor as the default model, and Cockpit becomes more important.

For migrations and operations, this means runbooks, screenshots, training and automation need review. Old assumptions about wicked, YaST modules, AppArmor profiles or module repositories should not be carried forward unchecked. A typical old reflex “check wicked” becomes `nmcli connection show`; “check AppArmor profile” becomes `getenforce`, `sestatus` and audit analysis; “configure everything through YaST” becomes Agama for installation, Cockpit/CLI for interactive administration and Ansible for reproducible configuration.

Final Acceptance Check

A SLES 16 installation is complete only when the system boots, is registered, repositories are usable, no units have failed, network and time are correct, SELinux runs in the intended mode, firewall rules match the operating model, Snapper works, Cockpit is reachable and the patch process has been tested.

The disposable VM can be deregistered from SUSE Customer Center after update and screenshot validation is complete if the test entitlement should not remain bound. Until all evidence is complete, keep it registered so repository and patch checks remain reproducible.

Professional Support