Introduction to SLES Minimal VM

SLES Minimal VM is a set of ready-to-run virtual machine images that let you deploy SUSE Linux Enterprise Server without running an installer. Each image includes a lightweight system, serving as a foundation for building systems for use in a data center, creating virtual application images and building appliances. Because the images contain fewer packages, they require less patching and expose fewer potential security vulnerabilities.

The following differences affect how you deploy and operate the system:

The image you choose determines the hypervisor you can run it on and how the system is configured on first boot. The initial configuration mechanism depends on your target environment.

Download the images from the official Download page. Images have the platform in the name, based on their purpose:

By default, if you boot the virtual machine without providing an automated configuration method (such as Combustion or cloud-init), the system launches JeOS Firstboot. To deploy the image interactively, manually complete this text-based wizard on the system console. Deploying involves two tasks:

Note: Exception for IBM Z

On s390x flavors targeting z/VM (such as DASD and FCP), the JeOS Firstboot wizard is not supported due to terminal limitations. On these images, systemd-firstboot is used instead.

Because starting a virtual machine varies wildly by platform, the exact procedure depends on your hypervisor. For Hyper-V and VMware images, use their management tools to create the virtual machine.

> qemu-system-x86_64 \
    -enable-kvm \
    -cpu host \
    -m 1G \
    -smp 1 \
    -drive if=virtio,format=qcow2,file=IMAGE.qcow2 \
    -nographic \
    -netdev user,id=net0,hostfwd=tcp::2222-:22 \
    -device virtio-net-pci,netdev=net0

> virt-install \
    --name VM_NAME \
    --memory 1024 \
    --vcpus 1 \
    --import \
    --disk IMAGE.qcow2,bus=virtio \
    --osinfo detect=on,require=off

5.2 Configuring a system with JeOS Firstboot #

 

JeOS Firstboot is a text-based wizard that runs on the first boot and collects the basic settings. It appears on the console of the virtual machine, whichever platform you started it on.

1. Select the keyboard layout.

2. Read and accept the license agreement. You cannot proceed without accepting it.

3. Select the time zone.

4. Enter and confirm the root password.

5. Optionally, enroll keys for SSH access and create additional user accounts.

6. After the first boot, register the system. For more information, see Section 8, “Post-deployment configuration”. If you are only testing the image, you can skip registration.

Tip: Reconfiguring settings with jeos-config

If you need to change these settings after the initial deployment, you can use jeos-config. Running this command as root opens an interactive text-based tool where you can adjust your initial choices.

SLES Minimal VM comes with the Combustion configuration tool, which configures the system on first boot from a script that you supply. This can be particularly useful when you need to deploy multiple virtual machines with an identical initial configuration. When Combustion runs successfully, JeOS Firstboot does not start. Because Minimal VM does not configure a default root password, the script must include a login method, either a root password or an SSH public key for remote access.

By default, Combustion produces no output while it runs. The indication that it worked is that JeOS Firstboot does not start and you can log in as root using the method you configured in the script.

The cloud Minimal VM image uses cloud-init to configure the system on first boot from a user-data file. Deploying with cloud-init has two parts: writing the configuration and making it available to the virtual machine through a data source.

If no data source is provided, the system defaults to JeOS Firstboot on initial boot.

Note: Scope of the cloud-init section

This section applies to the cloud image on a local hypervisor, where cloud-init uses the NoCloud data source.

On OpenStack and other cloud platforms, supply your user-data through the interface of the platform. For the data sources that cloud-init supports, see https://docs.cloud-init.io/en/latest/reference/datasources.html#datasources-supported.

7.1 How to write the user-data file #

 

To deploy the image with cloud-init, you must first create the user-data file. The first line of the file must be #cloud-config.

To view the default SUSE configuration for cloud-init, check the /etc/cloud/cloud.cfg file provided by the cloud-init-config-suse package.

By default, cloud-init does not set a root password. Instead, it creates a user account called sles that acts as the default user and has sudo rights. Use the following example to create passwords for both users.

Example 1: Add passwords #

 

#cloud-config
chpasswd:
  list: |
    root:$6$HdJCmMKHZT2NLcwv$4cRJ4yGGmDpPIvt0pqSa3KeEOKMKT8vR4DrYX23LlYrvM6suF79CzWomCFyreiT645fWVaFXMtyUM5zFOJMa9/
    sles:$6$HdJCmMKHZT2NLcwv$4cRJ4yGGmDpPIvt0pqSa3KeEOKMKT8vR4DrYX23LlYrvM6suF79CzWomCFyreiT645fWVaFXMtyUM5zFOJMa9/
  expire: False

To create the SHA-512 hashes used in the example, run the command: openssl passwd -6.

Warning: User passwords

To prevent potential security risks, avoid using passwords in production environments. When using hashed passwords, you are exposed to dictionary attacks. For better security, use SSH authentication instead.

However, local logins, for example, in a recovery scenario, still require a password. This is why setting a root password, as shown in the previous example, might still be necessary even when you use SSH keys for regular access.

When creating users, keep in mind that logging in with a password is disabled by default (lock_passwd: true), and that the newly created users do not have sudo rights.

The following examples show configurations for creating different users.

Example 2: New user with password and sudo #

 

#cloud-config
users:
  - default
  - name: USER
    shell: /bin/bash
    groups: users
    # lock_passwd: Disable password login. Defaults to true
    lock_passwd: false
    passwd: HASH
    sudo: ALL=(ALL) NOPASSWD:ALL

Example 3: New user with SSH keys and sudo #

 

#cloud-config
users:
  - name: USER
    shell: /bin/bash
    groups: users
    ssh_import_id: None
    lock_passwd: true
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - SSH_PUBLIC_KEY_1
      - SSH_PUBLIC_KEY_2

To connect and register with the SUSE Multi-Linux Manager, RMT or SUSEConnect, use runcmd to run the desired commands, for example:

Example 4: SUSEConnect configuration #

 

#cloud-config
runcmd:
  - SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS

Example 5: RMT configuration #

 

#cloud-config
runcmd:
 - curl --output rmt-client-setup http://RMT_SERVER/tools/rmt-client-setup
 - sh rmt-client-setup --host RMT_SERVER
     --regcert http://RMT_SERVER/rmt.crt
     --fingerprint FINGERPRINT --yes

Replace FINGERPRINT with the output of the following command that you run on your RMT server:

> sudo openssl x509 -noout -fingerprint -in /etc/rmt/ssl/rmt-ca.crt

For example: 0F:1F:2F:3F:4F:5F:6F:7F:8F:9F:AF:BF:CF:DF:EF:FF.

For further information, see https://documentation.suse.com/sles-15/html/SLES-all/cha-rmt-client.html.

Example 6: SUSE Multi-Linux Manager configuration #

 

#cloud-config
runcmd:
  - curl -SksO https://SERVER_HOSTNAME/pub/bootstrap/bootstrap.sh
  - /bin/bash bootstrap.sh

For further information, see https://documentation.suse.com/multi-linux-manager/en/docs/client-configuration/registration-bootstrap.html.

The following example shows a configuration that installs a package and starts a service during the first boot.

Example 7: Add PACKAGE and start a service #

 

#cloud-config
packages:
  - PACKAGE
runcmd:
  - systemctl enable SERVICE.service
  - systemctl start --no-block SERVICE.service

Note: Optional configuration files

You can optionally create other configuration files, called meta-data, network-config and vendor-data. For more information, see https://docs.cloud-init.io/en/latest/reference/datasources/nocloud.html.

After you write the user-data file, provide the file to the virtual machine, as described in the following section.

> virt-install \
    --name VM_NAME \
    --memory 1024 \
    --vcpus 1 \
    --import \
    --disk IMAGE.qcow2,bus=virtio \
    --cloud-init user-data=./user-data \
    --osinfo detect=on,require=off

After successfully deploying and configuring your SLES Minimal VM, the system is running and ready for use. To ensure optimal security and localization, perform the following post-deployment tasks.

> sudo SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS

> sudo zypper patch

8.4 Removing setup packages #

 

JeOS Firstboot and the packages it pulls in are only required for the initial configuration of the system. You can leave these packages on the system, or, when the system is fully configured and you do not intend to reconfigure it, you can safely remove the wizard together with the dependencies:

> sudo zypper remove -u jeos-firstboot

Note: Configuration tools are removed as well

The command removes JeOS Firstboot along with dependencies, including configuration tools such as jeos-config or ssh-pairing. If you still need any of these tools, keep JeOS Firstboot installed.

Copyright© 2006– 2026 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.

For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.