diff --git a/DC-SAP-Minimal-VM b/DC-SAP-Minimal-VM
new file mode 100644
index 000000000..15b03f81b
--- /dev/null
+++ b/DC-SAP-Minimal-VM
@@ -0,0 +1,16 @@
+# This file originates from the project https://github.com/openSUSE/doc-kit
+# This file can be edited downstream.
+
+MAIN="sle-minimal-vm.asm.xml"
+SRC_DIR="articles"
+IMG_SRC_DIR="images"
+
+## Profiling
+PROFOS="sles4sap"
+#PROFCONDITION="16.0"
+#PROFARCH="x86_64;power"
+
+DOCBOOK5_RNG_URI="urn:x-suse:rng:v2:geekodoc-flat"
+
+STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns"
+FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse-ns"
\ No newline at end of file
diff --git a/DC-SLES-Minimal-VM b/DC-SLES-Minimal-VM
new file mode 100644
index 000000000..58f80cb95
--- /dev/null
+++ b/DC-SLES-Minimal-VM
@@ -0,0 +1,16 @@
+# This file originates from the project https://github.com/openSUSE/doc-kit
+# This file can be edited downstream.
+
+MAIN="sle-minimal-vm.asm.xml"
+SRC_DIR="articles"
+IMG_SRC_DIR="images"
+
+## Profiling
+PROFOS="sles"
+#PROFCONDITION="16.0"
+#PROFARCH="x86_64;zseries;power;aarch64"
+
+DOCBOOK5_RNG_URI="urn:x-suse:rng:v2:geekodoc-flat"
+
+STYLEROOT="/usr/share/xml/docbook/stylesheet/suse2022-ns"
+FALLBACK_STYLEROOT="/usr/share/xml/docbook/stylesheet/suse-ns"
\ No newline at end of file
diff --git a/articles/sle-minimal-vm.asm.xml b/articles/sle-minimal-vm.asm.xml
index 2a4f62b3e..e78de1c7e 100644
--- a/articles/sle-minimal-vm.asm.xml
+++ b/articles/sle-minimal-vm.asm.xml
@@ -1,7 +1,6 @@
-
-
+
+
@@ -14,17 +13,37 @@
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:trans="http://docbook.org/ns/transclusion"
xmlns:its="http://www.w3.org/2005/11/its"
+ xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns="http://docbook.org/ns/docbook">
+
-
-
-
-
-
-
+
+ What is &sleminvm;?
+
+
+ Choosing the right deployment image
+
+
+ Differences between &sleminvm; and &productname;
+
+
+ Obtaining &minvm; images
+
+
+
+
+
+ Deploying an image with cloud-init
+
+
+ Deploying an image without cloud-init
+
+
+ Deploying an image without cloud-init
+
@@ -36,26 +55,11 @@
-
+
- Introduction to &minvm;
-
-
- 2024-02-09
-
-
- Revised and restructured the content
-
-
-
- 2023-10-10
-
-
- Revised the content
-
-
-
- 2023-05-02
+ Introduction to &sleminvm;
+
+ 2026-08-20
Initial version
@@ -63,97 +67,103 @@
-
-
-
-
- &x86-64;
- &zseries;
- &power;
- &aarch64;
+
+ &x86-64;&power;&zseries;&aarch64;
-
-
- &productname;
+ &productname;
-
- Introduction to &minvm;
- How to set up and use &minvm;.
-
- Set up &minvm;
-
-
- Virtualization
+ Introduction to &sleminvm;
+ Learn what &sleminvm; images are, which ones are available, and how to deploy them with or without cloud-init
+ How to set up and use &sleminvm;
+
+ Containers and virtualization
+
+ VirtualizationDeployment
-
Products & Solutions
-
https://bugzilla.suse.com/enter_bug.cgiDocumentation
- SUSE Linux Enterprise Server &productnumber;
+ SUSE Linux Enterprise Server &productnumber;
+ SUSE Linux Enterprise Server for SAP applications &productnumber;eliska.romanova@suse.comyes
-
-
- WHAT?
-
-
- A high-level overview of &minvm;.
-
-
-
-
- WHY?
+
+ &sleminvm; images allow you to run &productname; in a virtual or cloud environment
+ without having to perform a full installation. Learn which &minvm; image to choose, the
+ ways to deploy them and how to configure them on first boot.
+
+
+
+ Prerequisites:
+
+
- You want to know what &minvm; can do for you.
+ General familiarity with &productname;
-
-
- EFFORT
-
-
- 10 minutes of reading time.
-
-
-
-
- GOAL
-
-
- Get an understanding of what &minvm; is and what it can be used for.
-
-
-
-
- REQUIREMENTS
-
-
-
-
- General familiarity with &sles;
-
-
-
-
-
-
+
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/common/generic-entities.ent b/common/generic-entities.ent
index 0ca2e2b31..7779c1ee3 100644
--- a/common/generic-entities.ent
+++ b/common/generic-entities.ent
@@ -89,7 +89,8 @@
-
+
+
diff --git a/concepts/minimal-vm-get.xml b/concepts/minimal-vm-get.xml
index 732823938..0cd393789 100644
--- a/concepts/minimal-vm-get.xml
+++ b/concepts/minimal-vm-get.xml
@@ -1,4 +1,6 @@
+
+
@@ -12,49 +14,47 @@
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:trans="http://docbook.org/ns/transclusion">
- Obtaining &minvm;
-
+ Obtaining &minvm; images
+
+
+
+ Learn how to download and identify the correct &minvm; images for your target platform
+
+
- You can download the desired variant of &minvm; from the official Download page. The page offers the following &minvm; versions:
-
-
-
-
- Fully virtual &minvm; for &kvm; and &xen;
-
-
-
-
- &minvm; for &vmware;
-
-
+ Download the images from the official
+ DownloadDownload
+ page. Images have the platform in the name, based on their purpose:
+
+
-
- &minvm; for &hyperv;
-
+
+ Cloud for cloud platforms
+
-
- &minvm; for &ostack;
-
+
+ kvm-and-xen for &kvm; and &xen; hypervisors
+
+
-
- Paravirtual &minvm; for &xen;
-
+
+ MS-HyperV for &hyperv; hypervisors
+
-
- Fully virtual &minvm; for &kvm; for &aarch64;
-
+
+ VMware for &vmware; hypervisors
+
-
-
- SUSE subscription required
-
- By default, &minvm; does not have any repositories. You must register
- your system to access online repositories. Registration requires a paid subscription.
-
-
+
+
+ &sleminvm; architecture availability
+
+ Ready-to-use &sleminvm; images are currently available for the x86_64 architecture only. The
+ images for &power; are planned to be available in a future release.
+
+
diff --git a/concepts/minimal-vm-highlights.xml b/concepts/minimal-vm-highlights.xml
deleted file mode 100644
index 74bfd9e86..000000000
--- a/concepts/minimal-vm-highlights.xml
+++ /dev/null
@@ -1,72 +0,0 @@
-
-
- %entities;
-]>
-
-
- &minvm; highlights
-
-
-
-
-
- &minvm; is available as preconfigured and ready-to-run virtual
- machine images.
-
-
-
-
- While you can deploy the provided images as is, it is also possible to
- create customized &minvm; images using the supplied &kiwi; templates.
-
-
-
-
- The supplied jeos-firstboot wizard runs on the
- first boot and allows you to configure basic settings, such as system
- locales and the &rootuser; password.
-
-
- Instead of jeos-firstboot, &minvm; for &ostack;
- uses cloud-init for configuring &ostack; instances.
-
-
-
-
- You can establish an SSH connection to the running &minvm; instance
- without any further configuration.
-
-
-
-
- The default network configuration is set to use DHCP.
-
-
-
-
- The system automatically creates a Btrfs snapshot after the initial configuration has been completed. This means that you can easily revert all subsequent
- changes, if necessary.
-
-
-
-
- &minvm; images use the
- kernel-default-base as the default kernel, which
- results in a smaller footprint.
-
-
-
-
- As &opensuse; Leap &minvm; and &minvm; are similar, it is easy to migrate from the former to the latter.
-
-
-
-
diff --git a/concepts/minimal-vm-image.xml b/concepts/minimal-vm-image.xml
new file mode 100644
index 000000000..42b017c6b
--- /dev/null
+++ b/concepts/minimal-vm-image.xml
@@ -0,0 +1,74 @@
+
+
+
+
+ %entities;
+]>
+
+
+ Choosing the right deployment image
+
+
+
+ Learn how to choose the right deployment image and configure it on first boot
+
+
+
+
+ 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.
+
+
+
+ Cloud platforms
+
+
+ On cloud platforms, the image is configured automatically on first boot by
+ cloud-init. You provide your configuration instructions through the
+ configuration file. If no cloud-init configuration is supplied, the
+ deployment falls back to the interactive &jeosfirstboot; wizard.
+
+
+
+
+ Virtualization platforms
+
+
+ Virtualization platforms (&kvm;, &vmware;, &hyperv;) do not include
+ cloud-init and offer two configuration paths for the first boot:
+
+
+
+
+ Interactive (default): The &jeosfirstboot; wizard prompts you to set timezone,
+ passwords, create a standard user, and more.
+
+
+ Exception for &zseries;
+
+ On &s390x; flavors targeting z/VM (such as DASD and FCP), the &jeosfirstboot;
+ wizard is not supported due to terminal limitations. On these images,
+ systemd-firstboot is used instead.
+
+
+
+
+
+ Automated: If you require an unattended, automated deployment, you can use
+ &combustion; to bypass the &jeosfirstboot; wizard.
+
+
+
+
+
+
+
diff --git a/concepts/minimal-vm-intro.xml b/concepts/minimal-vm-intro.xml
index 6aa1b625a..67495f491 100644
--- a/concepts/minimal-vm-intro.xml
+++ b/concepts/minimal-vm-intro.xml
@@ -1,4 +1,6 @@
+
+
@@ -12,15 +14,161 @@
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:trans="http://docbook.org/ns/transclusion">
- Introduction to &minvm;
-
+ What is &sleminvm;?
+
+
+
+ Learn about the capabilities, deployment methods, and system defaults of &sleminvm;
+
+
-
- &minvm; is a slimmed-down version of &sles; designed to act as a foundation
- for building systems for use in a data center, creating virtual application
- images and building appliances. It can be customized by installing only
- packages required for the specific use case. This means that there are
- fewer packages to manage and patches to apply. The limited selection of
- packages also makes the system more secure by reducing the attack surface.
+
+ &sleminvm; is a set of ready-to-run virtual machine images that let you deploy &productname;
+ without running an installer. Each image includes a lightweight system with the &sap; base
+ pattern already installed, 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.
+
+ &sleminvm; is a set of ready-to-run virtual machine images that let you deploy &productname;
+ 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.
+
+
+
+ Deployment options
+
+
+ &sleminvm; is available as preconfigured and ready-to-run virtual machine images. It is
+ also possible to create customized &minvm; images using the supplied &kiwi; configuration
+ files, called templates. They are provided by the
+ kiwi-templates-Minimal package. For more information about how to use
+ KIWI templates, see
+ &kiwi;
+ Documentation.
+
+
+
+
+ &sap; pre-configuration
+
+
+ The &sap; base pattern is installed and &saptune; base tuning is applied, so the
+ operating system arrives prepared for an &sap; workload. For more information, see
+
+
+
+
+
+
+ Default configuration
+
+ The following settings are active as soon as a &minvm; image boots. They describe the state
+ of the system as shipped. For how &minvm; differs from an installed &productname; system, see
+ .
+
+
+
+ First-boot provisioning
+
+
+ On the cloud image, cloud-init configures the system on first boot
+ from a configuration you supply. If no configuration is provided, or if you are
+ deploying other image flavors, the &jeosfirstboot; wizard runs on first boot and allows
+ you to configure basic settings, such as system locales and the &rootuser; password.
+ Alternatively, you can use &combustion; for a fully automated system configuration.
+
+
+
+
+ Access and remote authentication
+
+
+ SSH on TCP port 22 is enabled as the default externally accessible port. Remote
+ password-based &rootuser; login is disabled by default.
+
+
+
+
+ cloud-init and &combustion; can be used to create a user account
+ and install SSH public keys supplied in the configuration.
+
+
+
+
+ When using &jeosfirstboot;, the wizard prompts you to set a local &rootuser;
+ password, create a standard user account, and enroll SSH public keys for remote
+ access.
+
+
+
+
+
+
+ Networking
+
+
+ The default network configuration uses DHCP, managed by &nm;.
+
+
+
+
+ Security and firewall
+
+
+ Because the &sap; base pattern is pre-installed, the &minvm; sets &selnx; to permissive
+ mode by default. The status of the host-based firewall depends on the image you deploy:
+
+
+ The &minvm; sets &selnx; to enforcing mode by default. The status of the host-based
+ firewall depends on the image you deploy:
+
+
+
+
+ On the cloud image, no firewall service is installed or enabled.
+
+
+
+
+ On the non-cloud images , the firewalld package is installed,
+ and the service is enabled and running by default.
+
+
+
+
+
+
+ Kernel
+
+
+ &sleminvm; images use the kernel-default-base as the default kernel,
+ which contains only a subset of kernel modules and firmware. This results in a smaller
+ image size.
+
+
+
+
+ System recovery
+
+
+ On the non-cloud images, the system automatically creates a Btrfs snapshot including
+ the initial configuration. This means that you can easily revert all subsequent
+ changes, if necessary.
+
+
+
+
+ Core dumps
+
+
+ Unlike in previous versions, systemd-coredump is enabled by default
+ in &sleminvm; &productnumber; to collect application core dumps for troubleshooting.
+
+
+
+
+
diff --git a/concepts/minimal-vm-on-kvm.xml b/concepts/minimal-vm-on-kvm.xml
deleted file mode 100644
index e6344d423..000000000
--- a/concepts/minimal-vm-on-kvm.xml
+++ /dev/null
@@ -1,162 +0,0 @@
-
-
- %entities;
-]>
-
-
- Examples of using &minvm; with &qemu;
-
-
-
- You can try &minvm; by downloading a ready-made image from the official
- Download
- page. The exact procedure for creating a &minvm;-based virtual machine
- depends on the version you choose. Below are examples of how to create and
- configure a &minvm; instance with &qemu; using either &jeosfirstboot; or &combustion;.
-
-
- Running and configuring &minvm; manually using &jeosfirstboot;
-
- Run the following command to create a &minvm; virtual machine in &qemu;.
-
-&prompt.user;qemu-system-x86_64 \
- -enable-kvm \
- -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
-
- After the system is booted, &jeosfirstboot; guides you through the
- initial system setup.
-
-
-
- Change locale
-
- The &minvm; image comes with the en_US locale
- only. You can install and select the desired system locale after the
- setup is completed by installing the glibc-locale
- package and running the localectl set-locale
- LANG=LOCALE command (replace
- LOCALE with the desired language locale,
- for example, de_DE.UTF-8).
-
-
- Keep in mind that to do this, you need to have a &suse; subscription and
- register the VM using the SUSEConnect -e
- EMAIL -r
- REGISTRATION_CODE command.
-
-
-
-
- As the first step, you are prompted to select the appropriate
- keyboard layout using the keyboard selection dialog.
-
-
-
-
- Next, read and accept the License Agreement. You cannot proceed
- without accepting the license agreement.
-
-
-
-
- Specify the desired time zone.
-
-
-
-
- When prompted, specify and confirm the desired &rootuser; password.
-
-
-
-
- As the last step, you are instructed to register your system. If you
- only plan to test &minvm;, you can skip registration.
-
-
-
-
- After the initial configuration is completed, you can log in to the
- system as root, using the password you specified
- during the setup procedure.
-
-
-
-
- Installing product patches after first boot
-
- After &minvm; has been successfully installed and registered, we highly
- recommend installing the latest available online updates.
-
-
-
-
- Running and configuring &minvm; automatically using &combustion;
-
- &minvm; comes with the &combustion; configuration tool, which makes it
- possible to automatically configure the system on first boot using a
- dedicated script file. This can be particularly useful when you need to
- deploy multiple virtual machines with an identical initial configuration.
-
-
- To trigger the &combustion; tool in &qemu;, use the
- qemu command with the fw_cfg
- parameter, which specifies the location of the script
- file.
-
-
- To see how this works in practice, you can use a simple &combustion;
- script that automatically adds the &rootuser; user to the &minvm;
- instance running in &qemu;.
-
-
- First, generate a hash of the desired &rootuser; password. This can be
- done using the openssl passwd -6 command. Add the
- following instruction to the script file (replace
- the example hash with the generated one):
-
-echo 'root:$5$.wn2BZHlEJ5R3B1C$TAHEchlU.h2tvfOpOki54NaHpGYKwdNhjaBuSpDotD7' | chpasswd -e
-
- Set up a new virtual machine based on &minvm; in &qemu; using the
- following command (replace IMAGE and
- SCRIPT with the path name of the
- .qcow2 image and the script
- file):
-
-&prompt.user;qemu-system-x86_64 \
- -enable-kvm \
- -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 \
- -fw_cfg name=opt/org.opensuse.combustion/script,file=SCRIPT
-
-
- Keep in mind that when &combustion; is running, it does not provide any
- feedback or output. The only indication that the configuration has been
- performed correctly is the fact that the system does not launch
- &jeosfirstboot; tool, and you can log in to the system as &rootuser;
- using the password you generated earlier.
-
-
- Combustion documentation
-
- For more information on using &combustion;, refer to .
-
-
-
-
diff --git a/concepts/minimal-vm-vs-sles.xml b/concepts/minimal-vm-vs-sles.xml
index 7d970e670..a54390053 100644
--- a/concepts/minimal-vm-vs-sles.xml
+++ b/concepts/minimal-vm-vs-sles.xml
@@ -1,4 +1,6 @@
+
+
@@ -12,146 +14,160 @@
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:trans="http://docbook.org/ns/transclusion">
- Differences between &minvm; and &sls;
-
+ Differences between &sleminvm; and &productname;
+
+
+
+ This section outlines the primary configuration, kernel and storage differences between
+ &minvm; images and standard &productnameshort; deployments
+
+
- There are several significant differences between &minvm; and &sls;.
+ The following differences affect how you deploy and operate the system:
-
+
- &jeosfirstboot;
+ No installation step
- &minvm; comes with the &jeosfirstboot; tool (except
- &minvm; for &ostack;, which uses cloud-init) that
- can be used to configure basic settings during the first boot. This
- includes keyboard layout, time zone and &rootuser;
- password.
+ There is no installer to run. The images are ready to boot, and basic settings are
+ configured on first boot by the &jeosfirstboot; tool, by &combustion;, or by
+ cloud-init on the cloud image.
- kernel-default-base
+ No repositories by default
- Because of size constraints, &minvm; images use the
- kernel-default-base as the default kernel. Since
- the kernel does not contain drivers for bare metal, this allows for a
- smaller footprint.
-
-
- If a specific usage scenario requires any of the omitted modules,
- install the kernel-default package to get a full
- tree of the kernel modules. This is the same kernel used by a regular
- &sls; installation.
+ The &minvm; images contain no repositories. Register the system to access online
+ repositories. Registration requires a paid subscription.
- No repositories by default
+ Reduced kernel
- When installing a &sls; from the installation media, the system
- automatically sets the installation media as the default offline
- channel.
+ To keep the image small, &minvm; uses kernel-default-base as the
+ default kernel. This kernel does not contain drivers for bare metal. If your scenario
+ requires additional drivers, install the kernel-default package to get
+ the full functionality. This is the kernel used by a regular installation.
-
-
- By default, the jeos-firstboot,
- jeos-licenses and
- live-langset-data packages do not receive
- updates. These packages are only required for the initial
- configuration of the system, and they can safely be removed or left
- untouched. If you prefer to keep them up to date, enable the Development Tools module.
-
-
-
- &zypper; configuration
+
+ Preinstalled &sap; patterns
- &minvm; is a slimmed-down version of &sls;. The reduction in size is
- achieved in part by enabling the following two options in
- /etc/zypp/zypp.conf:
- rpm.install.excludedocs = yes (excludes all files
- marked as documentation from being installed by default) and
- solver.onlyRequires = true (disables installation
- of suggested and recommended packages by default).
+ The images come with the &sap; base pattern preinstalled, so the system is already
+ prepared to receive an &sap; workload. To list the installed patterns, run the following
+ command:
+
+&prompt.sudo;zypper search --type pattern --installed-only
+
+ The output includes sles_sap_base_sap_server and
+ sles_sap_minimal_sap, alongside the base and &selnx; patterns.
-
- Base packages
+
+ Automatic base tuning
- &minvm; images are built using the &kiwi; tool. &kiwi;'s configuration
- files, called templates, list packages that must be included in the
- images. Keep in mind that packages listed in the template may pull
- required dependencies during the image building process. This means
- that the resulting image may contain more packages than those specified in the template.
+ Because the &sap; pattern pulls in &saptune;, base tuning is applied automatically. On
+ installation, &saptune; applies the SAP_Base solution, which
+ implements the recommendations of
+ &sapnote; 1275776.
+
+ Workload-specific tuning solutions
+
+ Base tuning is a starting point only. Apply the solution that matches your workload,
+ for example HANA, NETWEAVER,
+ S4HANA-APPSERVER or S4HANA-APP+DB. Only one
+ solution can be active at a time. For more information, see
+ How
+ to Tune Systems with &saptune;.
+
+
- Disk layout
+ &zypper; configuration
- Unlike &sls;, which calculates an adjustable disk layout proposal
- during installation, &minvm; features the following fixed virtual
- image partitioning scheme:
+ Part of the size reduction comes from two options in the &zypper; configuration:
- 2 MB BIOS boot
+ rpm.install.excludedocs = yes excludes all files marked as
+ documentation, such as man pages, from installation.
- 33 MB EFI system
-
-
-
-
- 24 GB Linux file system
+ solver.onlyRequires = true disables installation of suggested and
+ recommended packages.
+
+
+
+ Base packages
+
- To get additional disk space, you can either extend the existing disk
- from the virtual host or add a secondary disk to the virtual machine.
- If you choose the latter option, you must partition and format it
- manually.
+ The images are built from &kiwi; templates that list the packages to include. Keep in
+ mind that packages listed in a template can pull in dependencies during the build, so an
+ image usually contains more packages than the template names.
- systemd-coredump disabled
+ Predefined disk layout
- systemd-coredump is disabled by default on &minvm; images. To collect
- application core dumps necessary for troubleshooting, follow these
- steps:
+ Unlike &productname;, which calculates an adjustable disk layout proposal during
+ installation, &sleminvm; uses a predefined virtual image partitioning scheme:
- Install the systemd-coredump package, which
- contains /usr/lib/sysctl.d/50-coredump.conf.
+ 2 MB BIOS boot
- Reboot the system or use the sysctl --system
- command to enable core dumps.
+ 512 MB EFI system
+
+
+
+
+ 24 GB root file system in non-cloud deployments
+
+
+
+
+ A dynamically sized root file system in cloud deployments
+
+ The root file system holds the operating system and is not sized for &sap; data. Before
+ you deploy an &sap; workload, add storage for the &sap; file systems, for example,
+ /usr/sap, /hana/data, /hana/log
+ and /hana/shared, and configure swap according to the &sap; sizing
+ recommendations for your workload.
+
- For further information, refer to
- .
+ To add space, either extend the existing disk from the virtual host or add a secondary
+ disk to the virtual machine. If you extend the existing disk, the
+ kiwi-repart dracut module automatically resizes the root partition and
+ its file system to fill the available space during the next boot. If you add a secondary
+ disk, you must partition and format it manually.
diff --git a/tasks/minimal-vm-cloud-init.xml b/tasks/minimal-vm-cloud-init.xml
new file mode 100644
index 000000000..f4ec170c3
--- /dev/null
+++ b/tasks/minimal-vm-cloud-init.xml
@@ -0,0 +1,288 @@
+
+
+
+
+ %entities;
+]>
+
+
+ Deploying an image with <literal>cloud-init</literal>
+
+
+
+ Learn how to write a user-data configuration file and supply it as a
+ data source to deploy a cloud &minvm; image with cloud-init
+
+
+
+
+ The cloud &minvm; 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 &jeosfirstboot; on initial boot.
+
+
+ Scope of the <literal>cloud-init</literal> section
+
+ This section applies to the cloud image on a local hypervisor, where
+ cloud-init uses the NoCloud data source.
+
+
+ On &ostack; and other cloud platforms, supply your user-data through the
+ interface of the platform. For the data sources that cloud-init supports,
+ see
+ .
+
+
+
+ How to write the <filename>user-data</filename> 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 &rootuser; 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.
+
+
+ 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.
+
+
+ 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 &rootuser; 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.
+
+
+ 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
+
+
+ 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 &smlm;, &rmt;, or &suseconnect;, use
+ runcmd to run the desired commands, for example:
+
+
+ &suseconnect; configuration
+#cloud-config
+runcmd:
+ - SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS
+
+
+ &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:
+
+&prompt.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:GF:HF:IF:JF.
+
+
+ For further information, see
+ .
+
+
+
+ &smlm; configuration
+#cloud-config
+runcmd:
+ - curl -SksO https://SERVER_HOSTNAME/pub/bootstrap/bootstrap.sh
+ - /bin/bash bootstrap.sh
+
+ For further information, see
+ .
+
+
+
+ The following example shows a configuration that installs a package and starts a service
+ during the first boot.
+
+
+ Add <replaceable>PACKAGE</replaceable> and start a service
+#cloud-config
+packages:
+ - PACKAGE
+runcmd:
+ - systemctl enable SERVICE.service
+ - systemctl start --no-block SERVICE.service
+
+
+ Optional configuration files
+
+ You can optionally create other configuration files, called meta-data,
+ network-config and vendor-data. For more
+ information, see
+ .
+
+
+
+ After you write the user-data file, provide the file to the virtual
+ machine, as described in the following section.
+
+
+
+ Providing the user-data file to the virtual machine
+
+ Choose the method that matches your tooling.
+
+
+ Deploying with &qemu;
+
+ There are two ways to deliver the configuration: on a seed image attached as a CD-ROM, or
+ from a web server.
+
+
+
+
+ Make the configuration available to the virtual machine. Use either a seed image or a
+ web server:
+
+
+
+
+ Seed image: Create the seed image containing the
+ user-data file:
+
+&prompt.user;mkisofs \
+ -output seed.iso \
+ -volid cidata -rational-rock -joliet \
+ user-data
+
+
+
+ Web server: Copy the configuration file into a
+ directory served by a web server, for example,
+ /srv/www/htdocs/cloud-init/, served at
+ http://www.example.com/cloud-init/.
+
+
+
+
+
+
+ Start the virtual machine.
+
+&prompt.user;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 \
+ DATA_SOURCE_OPTION
+
+ Replace DATA_SOURCE_OPTION based on the chosen method from
+ the previous step:
+
+
+
+
+ If you use seed image data source:
+
+-drive file=seed.iso,media=cdrom
+
+
+
+ If you use web server data source:
+
+-smbios 'type=1,serial=ds=nocloud-net;s=http://www.example.com/cloud-init/'
+
+
+
+
+
+
+ Deploying with <command>virt-install</command>
+
+ If you deploy with &libvirt;, virt-install can generate the data source
+ for you:
+
+&prompt.user;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
+
+
+
diff --git a/tasks/minimal-vm-post-deployment.xml b/tasks/minimal-vm-post-deployment.xml
new file mode 100644
index 000000000..1bb5dc3dc
--- /dev/null
+++ b/tasks/minimal-vm-post-deployment.xml
@@ -0,0 +1,86 @@
+
+
+
+
+ %entities;
+]>
+
+
+ Post-deployment configuration
+
+
+
+ This section covers recommended post-deployment tasks for your &sleminvm;.
+
+
+
+
+ After successfully deploying and configuring your &sleminvm;, the system is running and ready
+ for use. To ensure optimal security and localization, perform the following post-deployment
+ tasks.
+
+
+ Registering the system
+
+ Registering your &sleminvm; links it to your &suse; subscription. If the system was not
+ registered during first boot, register it manually.
+
+&prompt.sudo;SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS
+
+ You can also register with &rmt; using the setup script. For more information, see
+ Configuring
+ clients with rmt-client-setup.
+
+
+
+ Installing system updates
+
+ After &sleminvm; is successfully installed and registered, it is highly recommended to
+ install the latest available online updates:
+
+&prompt.sudo;zypper patch
+
+
+ Changing the system locale
+
+ By default, the &sleminvm; image includes only the en_US locale. To use a
+ different system language, install and select your desired locale.
+
+
+
+
+ Install the locale package:
+
+&prompt.sudo;zypper install glibc-locale
+
+
+
+ Set the new locale. Replace LOCALE with your desired language
+ code, for example, de_DE.UTF-8:
+
+&prompt.user;localectl set-locale LANG=LOCALE
+
+ You can list all available system locales by running localectl
+ list-locales.
+
+
+
+
+
+ Removing setup packages
+
+ The jeos-firstboot and live-langset-data packages are
+ only required for the initial configuration of the system. You can leave these packages on
+ the system, or you can safely remove them after the first boot:
+
+&prompt.sudo;zypper remove jeos-firstboot live-langset-data
+
+
diff --git a/tasks/minimal-vm-without-cloud-init.xml b/tasks/minimal-vm-without-cloud-init.xml
new file mode 100644
index 000000000..1abb12999
--- /dev/null
+++ b/tasks/minimal-vm-without-cloud-init.xml
@@ -0,0 +1,254 @@
+
+
+
+
+ %entities;
+]>
+
+
+ Deploying an image without <literal>cloud-init</literal>
+
+
+
+ Learn how to configure non-cloud &minvm; images using interactive &jeosfirstboot; or
+ automated &combustion; deployment.
+
+
+
+
+ This section applies to the kvm-and-xen, Hyper-V and
+ VMware images, which do not contain cloud-init.
+
+
+ Before starting the virtual machine for the first time, choose one of the following deployment
+ methods:
+
+
+
+
+ Interactive setup (&jeosfirstboot;): Boot the virtual
+ machine normally and manually complete the text-based wizard on the system console.
+
+
+
+
+ Automated setup (&combustion;): Prepare a configuration
+ script and attach it to the virtual machine before powering it on. &combustion; applies the
+ settings automatically and bypasses the interactive wizard.
+
+
+ Exception for &zseries;
+
+ On &s390x; flavors targeting z/VM (such as DASD and FCP), the &jeosfirstboot; wizard is not
+ supported due to terminal limitations. On these images, systemd-firstboot
+ is used instead.
+
+
+
+
+
+ Interactive setup with &jeosfirstboot;
+
+ Deploying involves two tasks:
+
+
+
+
+ Start the virtual machine on your platform.
+
+
+
+
+ Configure the system on the first boot with &jeosfirstboot;.
+
+
+
+
+ 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.
+
+
+ Starting a &kvm; virtual machine
+
+ For kvm-and-xen images, you can start the virtual machine directly by
+ using &qemu; or virt-install.
+
+
+ &qemu;:
+
+&prompt.user;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:
+
+&prompt.user;virt-install \
+ --name VM_NAME \
+ --memory 1024 \
+ --vcpus 1 \
+ --import \
+ --disk IMAGE.qcow2,bus=virtio \
+ --osinfo detect=on,require=off
+
+
+
+ Configuring a system interactively with &jeosfirstboot;
+
+ &jeosfirstboot; 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.
+
+
+
+
+ Select the keyboard layout.
+
+
+
+
+ Read and accept the license agreement. You cannot proceed without accepting it.
+
+
+
+
+ Select the time zone.
+
+
+
+
+ Enter and confirm the &rootuser; password.
+
+
+
+
+ Optionally, enroll keys for SSH access and create additional user accounts.
+
+
+
+
+ After the first boot, register the system. For more information see
+ . If you are only testing the image,
+ you can skip registration.
+
+
+
+
+
+
+ Automated setup using &combustion;
+
+ &sleminvm; 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, &jeosfirstboot; does not start. Because &minvm; does not configure a
+ default &rootuser; password, it is mandatory to set it via the &combustion; script.
+
+
+
+
+ Generate a hash of your desired &rootuser; password:
+
+&prompt.user;openssl passwd -6
+
+
+
+ Create a configuration file named script. To ensure you can log in
+ to the &minvm; as the &rootuser; user, add the following line to the script, replacing
+ HASH with the value you just generated:
+
+echo 'root:HASH' | chpasswd -e
+
+ For more information about how to create the script, see
+ .
+
+
+
+
+ Make the script executable:
+
+&prompt.user;chmod +x script
+
+
+
+ Pass the script to the virtual machine. Use the method that matches your platform.
+
+
+
+ kvm-and-xen
+
+
+ Pass the script file directly with fw_cfg.
+
+
+ &qemu;:
+
+&prompt.user;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 \
+ -fw_cfg name=opt/org.opensuse.combustion/script,file=script
+
+ virt-install:
+
+&prompt.user;virt-install \
+ --name VM_NAME \
+ --memory 1024 \
+ --vcpus 1 \
+ --import \
+ --disk IMAGE.qcow2,bus=virtio \
+ --osinfo detect=on,require=off \
+ --sysinfo type=fwcfg,entry0.name="opt/org.opensuse.combustion/script",entry0.file="ABSOLUTE_PATH_TO_SCRIPT"
+
+
+
+
+ &hyperv;, &vmware; and other platforms
+
+
+ Provide the script on a storage device with the file system label
+ combustion, holding the script at
+ combustion/script.
+
+
+ To build such a device as an ISO image:
+
+&prompt.user;mkdir -p iso_root/combustion
+&prompt.user;mv script iso_root/combustion/
+&prompt.user;mkisofs -output combustion.iso -volid combustion -rational-rock iso_root
+
+ Create the virtual machine using your downloaded &minvm; image as the primary
+ virtual hard disk. Before booting the virtual machine for the first time, attach
+ combustion.iso as a virtual disc drive.
+
+
+
+
+
+
+
+ &combustion; produces no output while it runs. The indication that it worked is that
+ &jeosfirstboot; does not start and you can log in as &rootuser; with the password you
+ generated.
+
+
+
diff --git a/xml/concept-minimal-vm.xml b/xml/concept-minimal-vm.xml
deleted file mode 100644
index 2fc7011b1..000000000
--- a/xml/concept-minimal-vm.xml
+++ /dev/null
@@ -1,284 +0,0 @@
-
-
-
-
-
- %entities;
-]>
-
-
-
-
-
-
- Introduction to &slsa; &minvm;
-
-
- https://bugzilla.suse.com/enter_bug.cgi
- Smart Docs
- Documentation
- assignee@suse.com
-
- no
-
-
-
-
-
- Environment
-
- This document applies to the following products and product versions:
-
-
-
-
- &sles; 15 SP5, 15 SP4
-
-
-
-
-
- Decision card
-
-
- WHAT
-
-
- A minimal and versatile system you can customize for your specific use
- case
-
-
-
-
- WHY
-
-
- Because you want a lightweight but highly-adaptable and secure,
- easy-to-deploy system
-
-
-
-
- WHERE
-
-
- www.suse.com/download/sles
-
-
-
-
- EFFORT
-
-
- It only takes 7 minutes of reading time
-
-
-
-
- GOAL
-
-
- Learn what &slsa; &minvm; is and what you can use it for
-
-
-
-
-
-
-
-
- What is &slsa; &minvm;?
-
- You can easily figure out what &slsa; &minvm; is and what it does from its
- name. The &slsa; part reveals that it is a product
- derived from &sls;. Minimal means that you are getting a
- substantially slimmed-down version of &slsa;. And the VM
- abbreviation (it stands for Virtual Machine) points to the main usage
- scenario &slsa; &minvm; is built for: it can act as a foundation for
- building systems for use in a data center, creating virtual application
- images, and building appliances. In other words, &slsa; &minvm; is a nimble
- and versatile &slsa; variant that you can tailor for a wide range of uses.
-
-
- Because &slsa; &minvm; is based on &sls;, this gives you
- several important advantages right out of the box.
-
-
-
-
- Since both systems share the same code base, you do not have to certify
- &slsa; &minvm; if you already have &slsa; certification.
-
-
-
-
- The fact that you can customize &slsa; &minvm; by installing only the
- required components and nothing else means that there are fewer packages
- to manage and patches to apply. This also reduces the attack surface, thus
- making the resulting system more secure.
-
-
-
-
- &slsa; &minvm; features a lightweight Linux kernel, and the system is
- easy to deploy, extend, and customize.
-
-
-
-
-
-
-
- Highlights
-
-
-
- &slsa; &minvm; is available as pre-configured and ready-to-run virtual
- machine images.
-
-
-
-
- The supplied jeos-firstboot wizard runs on the
- first boot, and it allows you to configure basic settings, such as system
- locales and the root password. &slsa; &minvm; for &ostack; uses
- cloud-init for configuring &ostack; instances.
-
-
-
-
- &slsa; &minvm; comes with the SSH server enabled by default and excluded
- from the firewall configuration. This means that you can establish an SSH
- connection to the running system without any further configuration.
-
-
-
-
- The default network configuration is set to use DHCP, and the system
- automatically creates a Btrfs snapshot of the initial configuration. The
- latter means that you can easily revert all subsequent changes, if
- necessary.
-
-
-
-
- &slsa; &minvm; images use the
- kernel-default-base as the default kernel, which
- results in a smaller footprint.
-
-
-
-
- You can use the supplied KIWI templates to create customized &slsa;
- &minvm; images.
-
-
-
-
- As &opensuse; Leap &minvm; and &slsa; &minvm; are very similar, it is easy to migrate from the former to the latter.
-
-
-
-
-
- Keep in mind
-
-
-
- By default, &slsa; &minvm; has no software channels. You need to register
- your system to access online channels.
-
-
-
-
- While &sles; calculates the disk layout during installation, &slsa;
- &minvm; features the following fixed virtual image partitioning scheme
- (2MB BIOS boot, 33MB EFI boot, 24GB Linux file system). To get additional
- disk space, you can either extend the existing disk from the virtual host
- or add a secondary disk to the virtual machine.
-
-
-
-
- &slsa; &minvm; images have systemd-coredump
- disabled by default.
-
-
-
-
-
- Flavors
-
- While you can use &slsa; &minvm; as a foundation for creating a custom
- system for a specific use case, that does not mean you have to start from
- scratch every time you need to build a custom image. Instead, you can choose
- the following deployment targets from several ready-made images:
-
-
-
-
- Fully Virtual &slsa; &minvm; for KVM and Xen (FV/HVM)
-
-
-
-
- &slsa; &minvm; for VMware
-
-
-
-
- &slsa; &minvm; for Microsoft Hyper-V
-
-
-
-
- &slsa; &minvm; for &ostack;
-
-
-
-
- Paravirtual &slsa; &minvm; for Xen (PV)
-
-
-
-
- Fully Virtual &slsa; &minvm; for KVM for &aarch64;
-
-
-
-
-
- What to do next
-
-
-
- To learn more about &slsa; &minvm;, read the
- official
- documentation.
-
-
-
-
-