With VirtualBox you can take snapshots of the current state (without snapshot functionality of a filesystem like btrfs)

This kind of snapshot will create a kind of differential file and the original file will be untouched.

$  ls -lh ol9.vdi Snapshots/\{dfef3efe-1a67-466d-b968-835d7c2c915b\}.vdi
-rw------- 1 mnb mnb 463M Sep 25 17:55 '/Snapshots/{dfef3efe-1a67-466d-b968-835d7c2c915b}.vdi'
-rw------- 1 mnb mnb 9.5G Sep 25 17:52  ol9.vdi

Every changed block is written to this difference file in the Snapshot/ directory.

If you will do tests with always the same starting point, and after the test you will go back to the snapshot (restore). For this scenario it is a good solution. Virtualbox only needs to delete the differential file.

But if you take a snapshot before an upgrade, and if it is successful, you will keep this state and delete the snapshot state. For this scenario, VirtualBox has to copy all the blocks from the differential file back to the original file (ol9.vdi), which can be very time-consuming after patching big software (e.g. the OS or Oracle database).

You can also clone a VM with VirtualBox. You have the choice of a full- and a linked-clone. The full clone will create an independent copy of the disk files. The linked clone is only a snapshot of the disks of the source VM. So, the original disk will no longer be changed, but the original and the cloned VM will have an individual differential file in Snapshots/

ol9/ol9.iso  # will no longer be changed
ol9/Snapshots/{xxxxxxxxxxx}.vdi
ol9clone/Snapshots/{xxxxxxxxxxx}.vdi

This type of clone we should only use for short-term usage. Create a snapshot of the production, do some tests, and afterwards, immediately delete it! But after deleting the clone, you have to do a cleanup with the original VM. On the original VM, the snapshot is not deleted! (if you forget to delete it, you will need more and more diskspace…)

But is there a better solution? Yes, if you are using Linux. Use filesystem based file-snapshots.

Snapshots with btrfs

Some Linux filesystems with snapshots

• OCFS2: I used it often in the past, it works very well, but is not widely used. It is a cluster filesystem, but it can also be used for single-hosts.
• OpenZFS: I never used it.
• btrfs: Available in most Linux distributions (*) with subvolume snapshots. In this blog post I will show the examples with btrfs.

(*) Btrfs is no longer included in RedHat Enterprise linux and 1:1 forks like Rocky Linux. With these distributions, you can use the kernel from https://elrepo.org/. I used the “ml” Kernel and it worked well.
In Fedora (the development release of RedHat) btrfs is included. That means, there are political, not technical reasons that RedHat no longer delivers the modules for btrfs…
In Oracle Linux OL (also a RedHat fork) it is available with the UEK-kernel (a more modern Kernel than the RedHat Kernel). OL is freely available at https://yum.oracle.com.
SuSE uses btrfs as the default root filesystem.

A good overview of btrfs you will get with this SuSE article.

Your VMs are located in a directory. If you create a VM, you will specify the name and a directory (VM Folder)

Then, it creates the VM (virtual disks and configuration file) in the subdirectory /u00/virtualbox/vm1/

Snapshots with btrfs works with subvolumes. For us, for the application, a subvolume is visible as a directory. We can mount such a subvolume separately. And important for our use-case: we can create a snapshot of a subvolume.

[root@ltp14 virtualbox]  btrfs subvolume list .
ID 264 gen 1015763 top level 5 path virtualbox/olvmm01
ID 289 gen 1015763 top level 5 path virtualbox/winxp_2023-06-26
ID 290 gen 1015763 top level 5 path virtualbox/winxp
ID 292 gen 1015783 top level 5 path virtualbox/ol9
ID 307 gen 1015763 top level 5 path virtualbox/ubuntu2204
ID 354 gen 1015763 top level 5 path virtualbox/ol9a
ID 362 gen 1015763 top level 5 path virtualbox/ol9b

As you can see, most of my VMs are installed in subvolumes. I created a master image ol9, and ol9a and ol9b are snapshots of ol9 used for the “clone” functionality. And from my good old winxp installation i created a snapshot winxp_2023-06-26 which can be used similar to the “Snapshot” of virtualbox.

Difference of VirtualBox and btrfs

But what is the difference? As we have seen before, VirtualBox stores changed blocks in a separate file. If we access a virtual disk, we have to access 2 files. First check, if the block is in the snapshot file, and if not, take the unchanged block from the (no longer changed) original.

Btrfs is a copy-on-write filesystem. If we change a block, it will not change the current block on disk, instead, it allocates a new block and releases the old one. In case a snapshot exists, it will not release the old block as long as it is assigned in another snapshot.

[root@ltp14 virtualbox]  btrfs subvolume snapshot vm1 vm2

After we created the subvolume vm2 as a snapshot of subvolume vm1, fileA in both subvolumes share the same disk blocks, which is recorded in the inodes (mapping table between file and disk blocks). Of course, we can rename one of “FileA”, its inode assignment remains unchanged. If you update block 3 and 4 of fileA in vm1, then 2 new blocks are allocated (green, orange). If you update block 4 in vm2, then also a new block (light blue) is allocated and the old block (with white “x”) is deallocated (unused) because it is no longer allocated in any other snapshot.

For us, for the application, there are 2 independent files. There is no “original” and a snapshot file.

Snapshots

Subvolumes

Now, let’s see how to replace VirtualBox snapshot functionality by btrfs snapshots. Fist of all, we need a subvolume of our VM. Unfortunately, we can not convert an existing directory directly to a subvolume. We have to move the files in a subvolume.

[root@ltp14 virtualbox]  btrfs subvolume create vm1sub
Create subvolume './vm1sub'
[root@ltp14 virtualbox]  chown mnb:mnb vm1sub/  #subvols are created as root
[root@ltp14 virtualbox]  mv -v vm1/* vm1sub/
copied 'vm1/vm1.nvram' -> 'vm1sub/vm1.nvram'
removed 'vm1/vm1.nvram'
copied 'vm1/vm1.vbox' -> 'vm1sub/vm1.vbox'
removed 'vm1/vm1.vbox'
copied 'vm1/vm1.vbox-prev' -> 'vm1sub/vm1.vbox-prev'
removed 'vm1/vm1.vbox-prev'
copied 'vm1/vm1.vdi' -> 'vm1sub/vm1.vdi'
removed 'vm1/vm1.vdi'
[root@ltp14 virtualbox]  rmdir vm1
[root@ltp14 virtualbox]  mv vm1sub vm1
[root@ltp14 virtualbox]  btrfs subvolume list . |grep vm1
ID 367 gen 1016224 top level 5 path virtualbox/vm1
[root@ltp14 virtualbox]

Afterwards, we can use the VM as before.

Create a snapshot

Now we will create a snapshot of it. Ideally we stop it before the snapshot. If we snapshot a running VM, there may be some application inconsistencies. For Oracle databases, do an “alter database begin backup” before and end backup afterwards keeping the database recoverable. What we can not do with btrfs, is the snapshot of the memory, so we can not restore it “running”. VirtualBox can do that, but it is not “online”, Our VM is freezed during the time of the snapshot.

[root@ltp14 virtualbox]   sudo -u mnb vboxmanage controlvm vm1 shutdown  #or poweroff
[root@ltp14 virtualbox]  time  btrfs subvolume snapshot vm1 vm1_snap01
Create snapshot of 'vm1' in 'vm1_snap01'

real    0m0.030s
user    0m0.000s
sys     0m0.016s
[root@ltp14 virtualbox]  sudo -u mnb vboxmanage startvm vm1

Delete a snapshot

To delete a snapshot means, remove the subvolume of the old state. The big advantage compared to VirtualBox is, that we do not have to wait until the changed blocks are copied back in the “original” file. With btrfs, this is done “online” without influence of our running VM.

[root@ltp14 virtualbox]  btrfs subvolume delete vm1_snap

Restore a snapshot

To restore a snapshot means, renaming the subvolumes:

[root@ltp14 virtualbox]  sudo -u mnb vboxmanage controlvm vm1 poweroff
[root@ltp14 virtualbox]  mv vm1 vm1_bck
[root@ltp14 virtualbox]  btrfs subvolume snapshot vm1_snap01 vm1  #now the vm can be restarted
[root@ltp14 virtualbox]  btrfs subvolume delete vm1_bck  # (*)
Delete subvolume 367 (no-commit): '/u00/virtualbox/vm1_bck'

(*) in VirtualBox restoring a snapshot asks for “Create a snapshot of the current machine state” De-selecting this option is similar to delte the subvolume. And instead of “Create a snapshot…”, simply keep the renamed subvolume.

The “delete” snapshot of VirtualBox is equivalent to delete the current subvolume and rename the old subvolume back to the original name.

[root@ltp14 virtualbox]  sudo -u mnb vboxmanage controlvm vm1 poweroff
[root@ltp14 virtualbox]  btrfs subvolume delete vm1_snap
[root@ltp14 virtualbox]  mv vm1_snap vm1

Clone

The next subject is to clone a VM. I will demonstrate that by creating a master/template VM of Oracle Linux 10 (OL10) and then to create clones of it for different purposes.

Create a master VM

To define the VM you can start with the VirtualBox GUI. That will create the definition and an empty virtual disk. As described above, we will move it afterwards to a subvolume, then install and configure OL10 like every other VM.

After you have prepared the VM as a master-VM, that means you have installed all software you need in each clone, especially the VirtualBox tools, stop it and create clones.

Create a new VM from the master-VM

From the point of view of virtualbox, we create a full clone. From the point of view of the filesystem, it is similar to a linked clone (each VM stores its own modified blocks. But the old blocks are released when both VM’s have changed these blocks).

We create a subvolume ol10a from ol10, then we remove all files in ol10a, except the disk image. This, we rename to ol10a.vdi. VirtualBox tracks the file by an uuid, so we have to set a new uuid for the cloned disk.

Tip: look at the space consumption before and after cloning (df -k).

[root@ltp14 virtualbox]   btrfs subvolume snapshot ol10 ol10a
Create snapshot of 'ol10' in 'ol10a'
[root@ltp14 virtualbox]  cd ol10a/
[root@ltp14 ol10a]  ls -l
total 3383436
drwx------ 1 mnb mnb         16 Sep 28 11:55 Logs
-rw------- 1 mnb mnb       4138 Sep 28 12:58 ol10.vbox
-rw------- 1 mnb mnb       6432 Sep 28 12:55 ol10.vbox-prev
-rw------- 1 mnb mnb 3466592256 Sep 28 12:58 ol10.vdi
[root@ltp14 ol10a]   rm -f *.vbox* Logs/*
[root@ltp14 ol10a]   mv ol10.vdi ol10a.vdi
[root@ltp14 ol10a]   VBoxManage internalcommands sethduuid /u00/virtualbox/ol10a/ol10a.vdi
UUID changed to: 81927ab2-e2ac-4143-9077-98af702ec82d

Afterwards, you can create a new VM with the GUI. But do not create an new disk. Attach the existing cloned disk.

You can also create the VM on commandline which is recommended if you need many clones. You can do it with your useraccount, or if you prefer to do all steps as root, with “sudo -u your_username”. First, create the VM, then attach/modify the desired virtual hardware (disk-controllers, ram, cpus, network, and attach the cloned virtual disk to a controller).

root@ltp14 ol10a]  sudo -u mnb  VBoxManage  createvm --name ol10a --basefolder /u00/virtualbox/ol10a --register
Virtual machine 'ol10a' is created and registered.
UUID: d983c059-2e2f-4e89-bad0-fd3676d567c7
Settings file: '/u00/virtualbox/ol10a/ol10a/ol10a.vbox'
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage modifyvm ol10a --memory 4096 --cpus 2 --ostype Oracle10_64 --vram 4
[root@ltp14 ol10a]  sudo -u mnb VBoxManage storagectl ol10a --name "SATA Controller" --add sata --controller IntelAhci
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage storagectl ol10a --name "IDE Controller" --add ide --controller PIIX4
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage storageattach ol10a --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium /u00/virtualbox/ol10a/ol10a.vdi
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage modifyvm ol10a --nic1 hostonly --hostonlyadapter1 vboxnet0
[root@ltp14 ol10a]  sudo -u mnb VBoxManage modifyvm ol10a --nic2 nat

Now you are ready to boot your cloned VM ol10a. This can be done from commandline (as your user) or in the VirtualBox GUI. After booting, log in and change immediately the hostname. Afterwards, adapt the clone for your needs.

hostnamectl hostname ol10a

L’article Snapshots with VirtualBox and btrfs est apparu en premier sur dbi Blog.

Looking at the host operating system we can see this is a SLE Micro 5.5:

suma:~ $ cat /etc/os-release 
NAME="SLE Micro"
VERSION="5.5"
VERSION_ID="5.5"
PRETTY_NAME="SUSE Linux Enterprise Micro 5.5"
ID="sle-micro"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sle-micro:5.5"

As this comes with a read only root file system we cannot directly use zypper to patch the system. The tool to use in this case is transactional-update. This still uses zypper in the background, but the updates are installed into a new Btrfs snapshot. Using this approach the running system is not touched at all and the updates only become available when the system is rebooted into the new snapshot (which happens automatically when the system is rebooted). If something is wrong with the new snapshot, the system can be booted from the old snapshot and the system is back to what it was before patching.

Before we patch the host system let’s have a look at the snapshots we currently have available:

suma:~ $ snapper list
 # | Type   | Pre # | Date                             | User | Used Space | Cleanup | Description           | Userdata     
---+--------+-------+----------------------------------+------+------------+---------+-----------------------+--------------
0  | single |       |                                  | root |            |         | current               |              
1  | single |       | Fri 08 Mar 2024 10:45:41 AM CET  | root |   1.30 GiB | number  | first root filesystem | important=yes
2  | single |       | Mon 07 Jul 2025 12:18:08 PM CEST | root |   1.51 MiB | number  | Snapshot Update of #1 | important=yes
3  | single |       | Mon 07 Jul 2025 12:30:01 PM CEST | root |   1.02 MiB | number  | Snapshot Update of #2 | important=yes
4  | single |       | Tue 08 Jul 2025 05:33:39 AM CEST | root |  39.78 MiB | number  | Snapshot Update of #3 | important=yes
5  | single |       | Wed 16 Jul 2025 09:25:23 AM CEST | root |  45.07 MiB |         | Snapshot Update of #4 |              
6* | single |       | Wed 23 Jul 2025 04:13:09 PM CEST | root |  58.62 MiB |         | Snapshot Update of #5 |         

Let’s patch and compare what we’ll have afterwards:

suma:~ $ zypper ref
Warning: The gpg key signing file 'repomd.xml' has expired.
  Repository:       SLE-Micro-5.5-Updates
  Key Fingerprint:  FEAB 5025 39D8 46DB 2C09 61CA 70AF 9E81 39DB 7C82
  Key Name:         SuSE Package Signing Key <build@suse.de>
  Key Algorithm:    RSA 2048
  Key Created:      Mon 21 Sep 2020 10:21:47 AM CEST
  Key Expires:      Fri 20 Sep 2024 10:21:47 AM CEST (EXPIRED)
  Rpm Name:         gpg-pubkey-39db7c82-5f68629b
Retrieving repository 'SLE-Micro-5.5-Updates' metadata ..............................................................................................................[done]
Building repository 'SLE-Micro-5.5-Updates' cache ...................................................................................................................[done]
Warning: The gpg key signing file 'repomd.xml' has expired.
  Repository:       SUSE-Manager-Server-5.0-Updates
  Key Fingerprint:  FEAB 5025 39D8 46DB 2C09 61CA 70AF 9E81 39DB 7C82
  Key Name:         SuSE Package Signing Key <build@suse.de>
  Key Algorithm:    RSA 2048
  Key Created:      Mon 21 Sep 2020 10:21:47 AM CEST
  Key Expires:      Fri 20 Sep 2024 10:21:47 AM CEST (EXPIRED)
  Rpm Name:         gpg-pubkey-39db7c82-5f68629b
Retrieving repository 'SUSE-Manager-Server-5.0-Updates' metadata ....................................................................................................[done]
Building repository 'SUSE-Manager-Server-5.0-Updates' cache .........................................................................................................[done]
Repository 'SLE-Micro-5.5-Pool' is up to date.                                                                                                                             
Repository 'SUSE-Manager-Server-5.0-Pool' is up to date.                                                                                                                   
All repositories have been refreshed.

suma:~ $ transactional-update 
Checking for newer version.
transactional-update 4.1.9 started
Options: 
Separate /var detected.
2025-07-30 09:42:32 tukit 4.1.9 started
2025-07-30 09:42:32 Options: -c6 open 
2025-07-30 09:42:33 Using snapshot 6 as base for new snapshot 7.
2025-07-30 09:42:33 /var/lib/overlay/6/etc
2025-07-30 09:42:33 Syncing /etc of previous snapshot 5 as base into new snapshot "/.snapshots/7/snapshot"
2025-07-30 09:42:33 SELinux is enabled.
ID: 7
2025-07-30 09:42:36 Transaction completed.
Calling zypper up
2025-07-30 09:42:38 tukit 4.1.9 started
2025-07-30 09:42:38 Options: callext 7 zypper -R {} up -y --auto-agree-with-product-licenses 
2025-07-30 09:42:39 Executing `zypper -R /tmp/transactional-update-JsIr01 up -y --auto-agree-with-product-licenses`:
Refreshing service 'SUSE_Linux_Enterprise_Micro_5.5_x86_64'.
Refreshing service 'SUSE_Manager_Server_Extension_5.0_x86_64'.
Loading repository data...
Reading installed packages...

The following 21 packages are going to be upgraded:
  boost-license1_66_0 libboost_system1_66_0 libboost_thread1_66_0 libpolkit-agent-1-0 libpolkit-gobject-1-0 mgradm mgradm-bash-completion mgrctl mgrctl-bash-completion polkit python3-pyparsing python3-pytz python3-PyYAML python3-requests python3-salt python3-simplejson python3-urllib3 salt salt-minion salt-transactional-update uyuni-storage-setup-server

21 packages to upgrade.

Package download size:    16.8 MiB

Package install size change:
              |      71.4 MiB  required by packages that will be installed
   654.0 KiB  |  -   70.8 MiB  released by packages that will be removed

Backend:  classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): y

...
2025-07-30 09:44:40 New default snapshot is #7 (/.snapshots/7/snapshot).
2025-07-30 09:44:40 Transaction completed.

Please reboot your machine to activate the changes and avoid data loss.
New default snapshot is #7 (/.snapshots/7/snapshot).
transactional-update finished

As noted above we must reboot the system for the updates to become active. Before we do that, let’s again have a look at the snapshots:

suma:~ $ snapper list
 # | Type   | Pre # | Date                             | User | Used Space | Cleanup | Description           | Userdata     
---+--------+-------+----------------------------------+------+------------+---------+-----------------------+--------------
0  | single |       |                                  | root |            |         | current               |              
1  | single |       | Fri 08 Mar 2024 10:45:41 AM CET  | root |   1.30 GiB | number  | first root filesystem | important=yes
2  | single |       | Mon 07 Jul 2025 12:18:08 PM CEST | root |   1.51 MiB | number  | Snapshot Update of #1 | important=yes
3  | single |       | Mon 07 Jul 2025 12:30:01 PM CEST | root |   1.02 MiB | number  | Snapshot Update of #2 | important=yes
4  | single |       | Tue 08 Jul 2025 05:33:39 AM CEST | root |  39.78 MiB | number  | Snapshot Update of #3 | important=yes
5  | single |       | Wed 16 Jul 2025 09:25:23 AM CEST | root |  45.07 MiB |         | Snapshot Update of #4 |              
6- | single |       | Wed 23 Jul 2025 04:13:09 PM CEST | root |   4.11 MiB |         | Snapshot Update of #5 |              
7+ | single |       | Wed 30 Jul 2025 09:42:32 AM CEST | root |  88.39 MiB |         | Snapshot Update of #6 |      

We got a new snapshot (number 7) which is not yet active, let’s reboot and check again:

suma:~ $ reboot
...
suma:~ $ snapper list
 # | Type   | Pre # | Date                             | User | Used Space | Cleanup | Description           | Userdata     
---+--------+-------+----------------------------------+------+------------+---------+-----------------------+--------------
0  | single |       |                                  | root |            |         | current               |              
1  | single |       | Fri 08 Mar 2024 10:45:41 AM CET  | root |   1.30 GiB | number  | first root filesystem | important=yes
2  | single |       | Mon 07 Jul 2025 12:18:08 PM CEST | root |   1.51 MiB | number  | Snapshot Update of #1 | important=yes
3  | single |       | Mon 07 Jul 2025 12:30:01 PM CEST | root |   1.02 MiB | number  | Snapshot Update of #2 | important=yes
4  | single |       | Tue 08 Jul 2025 05:33:39 AM CEST | root |  39.78 MiB | number  | Snapshot Update of #3 | important=yes
5  | single |       | Wed 16 Jul 2025 09:25:23 AM CEST | root |  45.07 MiB |         | Snapshot Update of #4 |              
6  | single |       | Wed 23 Jul 2025 04:13:09 PM CEST | root |   4.11 MiB |         | Snapshot Update of #5 |              
7* | single |       | Wed 30 Jul 2025 09:42:32 AM CEST | root |  88.39 MiB |         | Snapshot Update of #6 |            

The new snapshot became active and we’re fully patched on the host system.

Now that the host system is fully patched, we can proceed with patching the SUSE Multi Linux Manager application. Before we do that, let’s check what we currently have:

suma:~ $ mgradm inspect
10:40AM INF Welcome to mgradm
10:40AM INF Executing command: inspect
10:40AM INF Computed image name is registry.suse.com/suse/manager/5.0/x86_64/server:5.0.4.1
10:40AM INF Ensure image registry.suse.com/suse/manager/5.0/x86_64/server:5.0.4.1 is available
WARN[0002] Path "/etc/SUSEConnect" from "/etc/containers/mounts.conf" doesn't exist, skipping 
10:40AM INF 
{
  "CurrentPgVersion": "16",
  "ImagePgVersion": "16",
  "DBUser": "spacewalk",
  "DBPassword": "<REDACTED>",
  "DBName": "susemanager",
  "DBPort": 5432,
  "UyuniRelease": "",
  "SuseManagerRelease": "5.0.4.1",
  "Fqdn": "suma.dwe.local"
}

The currently running version is “5.0.4.1”. Patching is quite simple as this just updates the container:

suma:~ $ mgradm upgrade podman
10:41AM INF Welcome to mgradm
10:41AM INF Use of this software implies acceptance of the End User License Agreement.
10:41AM INF Executing command: podman
...
10:41AM INF No changes requested for hub. Keep 0 replicas.
10:41AM INF Computed image name is registry.suse.com/suse/manager/5.0/x86_64/server-hub-xmlrpc-api:5.0.5
10:41AM INF Ensure image registry.suse.com/suse/manager/5.0/x86_64/server-hub-xmlrpc-api:5.0.5 is available
10:42AM INF Cannot find RPM image for registry.suse.com/suse/manager/5.0/x86_64/server-hub-xmlrpc-api:5.0.5

Checking the version again:

suma:~ $ mgradm inspect
10:36AM INF Welcome to mgradm
10:36AM INF Use of this software implies acceptance of the End User License Agreement.
10:36AM INF Executing command: inspect
10:36AM INF Computed image name is registry.suse.com/suse/manager/5.0/x86_64/server:5.0.5
10:36AM INF Ensure image registry.suse.com/suse/manager/5.0/x86_64/server:5.0.5 is available
10:36AM ??? time="2025-07-30T10:36:20+02:00" level=warning msg="Path \"/etc/SUSEConnect\" from \"/etc/containers/mounts.conf\" doesn't exist, skipping"
10:36AM INF 
{
  "CurrentPgVersion": "16",
  "ImagePgVersion": "16",
  "DBUser": "spacewalk",
  "DBPassword": "<REDACTED>",
  "DBName": "susemanager",
  "DBPort": 5432,
  "UyuniRelease": "",
  "SuseManagerRelease": "5.0.5",
  "Fqdn": "suma.dwe.local"
}

Now we are on version “5.0.5” and we’re done with our patching for the server part. Clients also should be upgraded, especially the Salt client as SUSE Multi Linux Manager uses Salt to manage the clients. You can either do that manually by using the package manager of the distributions you’re managing or you can do that from the WebUI:

That’s it, not hard to do and an easy process to follow.

L’article Patching SUSE Multi Linux Manager est apparu en premier sur dbi Blog.

I am not going into the setup or basic configuration as you can already find related bogs here and more information in the documentation:

• Uyuni, an open-source configuration and infrastructure management solution for software-defined infrastructure (1) – The server (this is for version 4.x)
• Uyuni, an open-source configuration and infrastructure management solution for software-defined infrastructure (2) – Adding a client (this is for version 4.x)
• SUMA (SUSE Manager) is back and it has a new name: SUSE Multi-Linux
• SUSE Manager installation (this is for version 4)

What I want to look at in this post is automatic scheduling of OpenSCAP scans/reports. When this requirement came up, it seemed pretty easy to do, as you can easily schedule such a scan against a single system. As you can see below I have a Red Hat 9 system registered to my SUSE Multi Linux Server:

What you can easily do out of the box is to manually schedule an OpenSCAP scan:

Once the scan completes, it becomes visible under the “List Scan” tab and you can browse into the details:

Quite easy to do but still a manual action. As we wanted to have it automated the obvious choice was to create a “Recurring Action”:

This gives you to option to create and configure a “Recurring Action”:

The issue is, there is no pre-defined “Custom State” which is scheduling an OpenSCAP scan:

The very same is true for “System Groups”, which you normally would use because otherwise you’d need to schedule that on every single system:

The last option seemed to be something under “Schedule” but this only gives you a list of what you already have:

At this point we were stuck and had to talk to SUSE support, which really was a great experience by the way. It turned out there is no easy, build-in, way to do this. A feature request has been logged, but of course there is no guarantee that it will be implemented.

But, there is a workaround, not a very beautiful one, but at least it works. SUSE Multi Linux Manager (and Uyuni of course) come with an API and there is one call for triggering an OpenSCAP scan. Using this, a custom state channel can be created which in turn calls the API to trigger the scan:

The “SLS Contents” actually contains the code (Python in this case) which is taking to the API and triggers the scan:

/usr/local/bin/schedule_xccdf_scan.py:
  file.managed:
    - user: root
    - group: root
    - mode: 755
    - contents: |
        #!/usr/bin/python3
        import xmlrpc.client

        client = xmlrpc.client.ServerProxy('https://suma.dwe.local/rpc/api')
        key = client.auth.login('admin', 'xxxx')
        client.system.scap.scheduleXccdfScan(
            key,
            1000010000,
            '/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml',
            '--profile xccdf_org.ssgproject.content_profile_cis_server_l1'
        )
        client.auth.logout(key)

schedule_xccdf_scan:
  cmd.run:
    - name: /usr/local/bin/schedule_xccdf_scan.py
    - require:
      - file: /usr/local/bin/schedule_xccdf_scan.py

I am not going into the code itself, this should be easy to understand. The important part is the system ID in line 14. This defines the system you want the scan to happen on (you can also provide an array of systems, see the API documentation linked above).

As soon as you have this, you can schedule this automatically as a recurring action on either the system itself, or a group of systems in “System Groups”:

Not as easy as it could be, and the systems are still hard coded in the Python code, but at least we have something that works. Hope that helps.

L’article Scheduling OpenSCAP reports in SUSE Multi-Linux Manager est apparu en premier sur dbi Blog.

# First, check what repos are active with:
$ sudo zypper repos

# In case you only have SLES-Repositories on your system you can disable all of them at once. Otherwise you will be spammed with error messages when running zypper. To disable all repos in one shot, use:
$ sudo zypper modifyrepo --all --disable

# Now we come to the fun part. Depending on what minor version of release 15 you use, it is needed to change it inside the repository link. In my case I'm using 15.6:
$ slesver=15.6 && sudo zypper addrepo http://download.opensuse.org/distribution/leap/$slesver/repo/oss/ opensuse-leap-oss

# Now we only need to refresh the repositories and accept the gpg-keys:
$ sudo zypper refresh

# From now on we can install any packages we need without ever having to activate the system.

Disclaimer

This guide shows you how to swap out the paid SUSE Linux Enterprise Server (SLES) repositories, which are professionally managed and maintained by SUSE, for the open-source openSUSE Leap repositories. A community of volunteers, with some help from SUSE, drives and supports the openSUSE Leap repositories. But they lack the enterprise grade support, testing, and update guarantees provided by SLES. By following these steps, you will lose access to SUSE’s official updates, security patches, and support services tied to your expired SLES license. This process converts your system into a community supported setup, which may not align with production or enterprise needs. Proceed at your own risk, and ensure you understand the implications. Especially regarding security, stability, and compliance. To stay up to date with security announcements on OpenSUSE you can subscribe here.

L’article Use a expired SLES with OpenSUSE repositories est apparu en premier sur dbi Blog.

Prepare your SUSE/ SLES

The fact that OpenSUSE does not need any subscription means, that there is no need for cleanup at this point of my Blog. For all users that are using OpenSUSE: just jump to the Chapter 3.

Chapter 1: Cleanup of unused Modules or Add-ons

Before we start migrating or activating the system, ensure no unused or unneeded modules or add-ons linger on it. These could stop us from activating the system if our license doesn’t cover them.

To check for unneeded modules, open YaST and select ‘Software/Add-On Products.’ This lists all Add-On Products deployed on your system.

If the URL is defined as ‘Unknown URL,’ this Add-on either isn’t available anymore or changed its URL in future releases. Delete all Add-ons with missing URLs and check the ‘Software Manager’ in the bottom-right corner. Use the Software Manager to see if deleting an Add-on removes any packages.

Chapter 2: Activating and preparing SLES Subscription

This step is done in YAST or on the shell.

Shell:

# Check the Subscription of your SLES machine with SUSEConnect
$ SUSEConnect --status-text
# This will generate a list of all Repositories and Add-Ons used on your system and inform you about their state (Not Registered or Registered)
# Here is a example Output:
$ SUSEConnect --status-text | grep -i "not Registered" -B 3
SUSE Linus Enterprise Live Patching 
(sle-module-live-patching/15.2/x86_64)
Not Registered
--
Python 2 Module
(sle-module-python2/15.2/x86_64)
Not Registered
--
Desktop Applications Module
(sle-module-desktop-applications/15.2/x86_64)
Not Registered
--
HPC Module
(sle-module-hpc/15.2/x86_64)
Not Registered
--
SUSE Linux Enterprise Workstation Extension 15 SP2 
(sle-we/15.2/x86_64)
Not Registered

# The most important module on a SLES server is "sle-module-basesystem". This module has to be activated to be able to use the official SLES repositories.
# To activate the Base System Module run:
$ SUSEConnect -r ABCD1EF2GHIJKL34
Registering system to SUSE Customer Center
Updating system details on https://scc.suse.com...
Activating SLES 15.2 x86_64...
-> Adding service to svstem...
Activating sle-module-basesystem 15.2 x86 64...
-> Adding service to system...
-> Installing release package...
Activating sle-module-server-applications 15.2 286 64...
-> Adding service to svstem...
-> Installing release package...
Successfully registered system

# To activate specific modules you can run the SUSEConnect commands like this:
# The module name can be found inside the () when executing "SUSEConnect --status-text" 
$ SUSEConnect -p sle-we/15.2/x86_64 -r ABCD1EF2GHIJKL34

# In case you have issues with activating or connecting to the SUSE activation server "https://scc.suse.com" check the File /etc/SUSEConnect and/ or add a proxy inside your /etc/sysconfig/proxy:
$ cat /etc/SUSEConnect
---
url: https://scc.suse.com
insecure: false

# If your network is being limited or closed for http/ https connections add the following proxy settings inside the /etc/sysconfig/proxy file:
$ vi /etc/sysconfig/proxy
# Enable proxy forward
PROXY_ENABLED="yes"
# Configure a http proxy:
HTTP_PROXY="http://192.168.0.1:3128"
# Or a https proxy:
HTTPS_PROXY="http://192.168.0.1:3128"
# Here you can define which connections should not go over the proxy:
NO_PROXY="localhost, 127.0.0.1"

YaST:

The whole setup can be done via YaST too. So in case you don’t feel very comfortable inside the shell this is by far the most useful tool for system setup. To activate the SLES Base-System just start yast via GUI or run “yast2” in your shell:

Choose Software/ Product Registration:

Then choose “Register Again” to register your Base-System. Type in the “E-Mail Address” owning the SUSE-License and type in your “Registration Code”:

Afterwards you can choose “Select Extensions” to activate additional extensions:

If your registration code permits it, pick extra modules to use in your system:

Chapter 3: Online Migration (Minor Upgrade)

Now we can finally start with the Upgrade Process. Before jumping into execution it is smart to check the possibilities and upgrade paths that matches your systems version. You can find this in the official SUSE documentation: https://documentation.suse.com/sles/15-SP5/html/SLES-all/cha-upgrade-paths.html

In my example we will be doing a Online Upgrade from SLES 15-SP2 to SLES 15-SP5. You can tackle this step either on the shell with the ‘zypper migration’ command or through YaST.

Shell:

To kick off the online migration on the shell, run ‘zypper migration’—then pick the version you want to install when prompted. Before starting the migration zypper will also make sure to update all repositories and patch all security patches for your current version.

HINT: In some cases, disable interaction for the migration to keep the process rolling if a package demands a license agreement.

# Use zypper without any interruption by product license agreement:
$ zypper migration --auto-agree-with-product-licenses 

# Use zypper without any interruption at all:
$ zypper migration --non-interactive

This will look something like this:

YaST:

After the cleanup and the server activation, we can now open YaST and go to “Software/ Online Migration”. There, a short update of the repositories greets us, and we’ll see a list of possible upgrades:

In our case we will choose the (at that time) newest release SLES 15 SP5.

As of the end of January 2025, the latest release is SUSE Linux Enterprise Server (SLES) 15 SP6. Use this version — I recommend it since support for each service pack usually ends six months after the new one drops.

# It is possible to use YAST without interruption as well, this is suggested in bigger upgrades like here:
$ vi /etc/zypp/zypp.conf

# Add the parameter: 
$ autogreeWithLicenses = yes

Chapter 4: Offline Migration

When trying to upgrade any pre-SLES 15 system (like SLES 11 or 12), there is only the offline upgrade path available. This might sound harder than the one-click online migration, but in reality, it’s almost as easy as using YaST. The only difference is that you need to boot the server with the desired ISO version. In our example, my SLES 12 SP5 will need to be booted with the SLES 15 SP6 ISO. Depending on your server (and whether it’s bare metal or a VM), the specifics might vary case by case. In my case, I’m using a self-built virtualization server with OpenSUSE and running a KVM Server. The only thing I need to do to boot my SLES 15 SP6 ISO, is to mount the ISO file to my VM and disable secure boot. After that, reboot the VM and enter the “Upgrade” tab from your ISO. This will then start the step-by-step migration of your system.

After booting the ISO you will be greeted with these options. Choose “Update” to in-place upgrade your SUSE Enterprise Linux to the version of your ISO.

In case you use any other Filesystem than btrfs, use the checkbox “show All Partitions”. This will list even LVM volumes and filesystems.

II strongly suggest you check all the products you plan to install. If some aren’t needed or are missing, tick the ‘Manually Adjust the Repositories for Migration’ checkbox.

This step reminds us that the old SLES 12 SP5 repositories will be removed after the upgrade.

And the final step is a summary which we need to check carefully if all the settings are correct. After that the server will install the brand new release and boot it up after the installation process.

L’article Updating SUSE/ SLES the right way est apparu en premier sur dbi Blog.

It’s already impressive that Multi Linux Manager can handle almost anything you throw at it, but in the wild west of Linux distributions, that’s just not enough! SUSE has gone the extra mile by providing Linux engineers with brand-new repositories for ancient distributions like CentOS 6 or RHEL 5, as well as other dinosaurs that are still running along without a break. Yes, we can finally reassure the security officer at our company that the almost 20-year-old server is patched and secured to the latest standards. No need to re-engineer the entire system with a shiny new server or lose huge sums of money for extended support (if it even exists).

SUSE Multi-Linux Manager in a nutshell:

Lets shortly break down what SUSE Multi-Linux Manager offers you:

• Automated Patching and Updates:
  • Multi-Linux Manager automates patch management across your Linux environment, ensuring systems remain secure and compliant.
  • It uses certified software supply chains to deliver trusted patches and supports CVE (Common Vulnerabilities and Exposures) lists and OpenSCAP protocols for vulnerability scanning and compliance attestation.
  • You can automate updates for entire systems or specific packages, minimizing downtime and human error.
• Content Lifecycle Management (CLM):
  • Multi-Linux Manager includes tools for managing the lifecycle of software content, allowing you to test updates in staging environments before deploying them to production.
  • This ensures that no untested patches or updates are applied, reducing the risk of system instability.
• Real-Time Monitoring and Reporting:
  • Multi-Linux Manager provides real-time insights into the health and status of your Linux systems.
  • It offers portfolio-wide reporting for auditing, enabling you to track compliance and security across all managed clients, regardless of their location.
• Automation and Integration:
  • Multi-Linux Manager leverages Salt (a powerful configuration management tool) for automation, enabling one-click provisioning, patching, and configuration.
  • It integrates with other automation tools like Ansible, enhancing its flexibility in DevOps workflows.
  • Features like Cobbler (for bare-metal OS deployment) and Kiwi (for building OS images) further streamline system provisioning.
• Security and Compliance:
  • Multi-Linux Manager ensures the highest quality security by providing proactive updates, transparent roadmaps, and predictable lifecycles.
  • It offers auditing tools like OpenSCAP which provides you with a simple GUI based CIS scan and reporting.
• Containerized Deployment (SUSE Manager 5.0):
  • Starting with version 5.0, the Multi-Linux Manager server is delivered as a container image running on Podman. This decouples the server from the underlying OS, improving resilience and simplifying recovery.
  • If the server fails, administrators can spin up a new container and reattach the database, minimizing downtime.

Installing and Using SUSE Multi-Linux Manager

First of all we need to download the SUSE Multi-Linux Manager:
https://www.suse.com/download/suse-manager/

Please Make sure to download the “SUSE-Manager-Server.x86_64-5.0.2-SelfInstall-2024.12.install.iso” because even known the name is almost the same, the “SUSE-Manager-Proxy.x86_64-5.0.2-SelfInstall-2024.12.install.iso” will only install the proxy, which needs the SUSE Manager Server to run.

The Installation Process is straight forward and doesn’t need any explanation. If you need any help please check out the official SUSE Documentation: https://documentation.suse.com/suma/5.0/en/suse-manager/installation-and-upgrade/container-deployment/suma/server-deployment-vm-suma.html

After installation, you need to execute a few commands to use the web console, as described here:

# It is suggested that we activates the SUSE Micro 5.5 and the Multi-Linux Manager Server 5.0 before using it so it can be updated with the newest patches.
# First lets register the SUSE Micro:
transactional-update register -r <REGCODE> -e <your_email>
# Then reboot to activate the changes:
reboot
# Now its time to activate the Multi-Linux Manager Server:
transactional-update register -p SUSE-Manager-Server/5.0/x86_64 -r <REGCODE>
# After activation we can update/ patch the system:
transactional-update
# HINT Multi-Linux Manager Server can absolutely be used without any of the registration steps. The only command really needed to make the web console available:
mgradm install podman hostname.domain.ch

Now we can see the Multi-Linux Manager web console and login to it with the user “admin” and the password we configured at the installation:

Before bootstrapping any server, ensure that you connect your SUSE organization credentials to your Multi-Linux Manager Server. You can find your credentials at the SUSE Customer Center. This will require a existing SUSE License which we can add in: Admin > Organization Credentials:

After adding the SUSE License, we can now add the repositories needed for the bootstrapping process. A bootstrap repository contains the required packages for registering clients during bootstrapping. To bootstrap a SUSE Enterprise Linux 15 SP6, you need to add the following repositories:

For RHEL, CentOS, Debian, or Ubuntu, you can use these repositories:

Note that each of these repositories requires around 50-100 GB of storage, and for Ubuntu, it might even need over 100GB for each repository! So, make sure you have enough space or only activate the products you’ll use. #Ididthatmistake

Now, you can bootstrap all the servers that need managing with Multi-Linux Manager by going to System > System List > Add System:

Once the bootstrapping is complete, you can manage the server from Multi-Linux Manager. The possibilities for server management are nearly endless.

Automated OpenSCAP scan and auditing of servers:

The OpenSCAP scan feature is incredibly powerful, allowing you to execute security audits on servers. To use it, you simply go to the server you wish to check and choose Audit > OpenSCAP > Schedule. Now you only need to add these Command-Line Arguments like “–profile xccdf_org.ssgproject.content_profile_cis_server_l1 –report /tmp/oscap-suma-report.html” along with the path to the XML-Profile, which is usually “/usr/share/xml/scap/content/ssg-sle15-ds.xml”. You can execute it manually or schedule the scan or for recurring security checks.

Update & Patch installation/ management:

Multi-Linux Manager not only manages all repositories but also categorizes patches into various topics like “Security Patch” or “Bug fixes and Improvements” and more. It allows you to see which packages are not properly managed (e.g., not installed from a connected repository) and which ones are no longer updated.

For me, an important feature is the software channels where I can check all repositories connected to each server. Additionally it can help you analyze issues regarding missing repositories and/ or unneeded channels.

Remote commands:

With this tool, you can run any scripts or commands on one or multiple machines, scheduling them to execute with specified user and group privileges.

Summary & Takeaways:

SUSE Multi-Linux Manager (once known as SUSE Manager) can manage a wide variety of Linux systems, giving you one place to handle updates, security, and overall system management. Here’s what makes it special:

• Wide-Ranging Support: It works with all kinds of Linux, even very old versions like CentOS 6 or 7, keeping them safe and up-to-date.
• Automatic Updates: Makes updating your systems easier with automatic patches, keeping track of security issues, and ensuring your setups meet security standards, which helps prevent mistakes and downtime.
• Update Testing: Before applying updates everywhere, you can test them in a safe space to make sure they won’t cause problems.
• System Watch and Reports: Gives you live updates on how your systems are doing and offers detailed checks to keep everything secure and following rules.
• Automation Tools: Uses Salt to automate tasks, works well with Ansible, and has tools like Cobbler and Kiwi for setting up new systems, making things smoother for tech teams.
• Security Checks: Automatically scans your systems to make sure they’re up to security standards.
• Container Use: The latest version (5.0) uses containers, which makes it easier to set up, run, and recover if something goes wrong.
• Easy to get started: It’s easy to install, but remember, each Linux repository can take up a lot of space on your server (50-100GB or more).

SUSE Multi-Linux Manager offers a smart and modern way to manage Linux systems, making it a must-have for IT teams dealing with mixed Linux environments.

L’article SUMA (SUSE Manager) is back and it has a new name: SUSE Multi-Linux est apparu en premier sur dbi Blog.

I would like to thank Nico Lamberti in particular for the great collaboration we’ve had over the last few months. With his help, we have succeeded in strengthening synergies between SUSE and dbi services in terms of technical know-how and sponsorship. The success of our Rancher & NeuVector technical webinar and community events hosted by dbi and powered by Sequotech, such as the Data Community Conference perfectly illustrate our partnership with SUSE. That’s just a few examples, there’s many more joint events to come …

For my first participation at SUSECON, the objective was not only to participate in the technical sessions, follow the keynotes for new announcements or visit the technology presentation booths to discover SUSE products and sponsor demonstrations…. but also to reinforce our partnership, meet new people and freely share ideas on Linux, Cloud Native, Edge and AI.

Through this blog post, I’ll try to summarize what I discovered and what I learned!
I hope you’ll enjoy reading it.

The keynotes announcements.

The recent acquisition of StackState by SUSE was presented to the audience, who applauded warmly the arrival of this Ultimate Cloud Native offering in SUSE portfolio. StackState provides end-to-end observability capabilities, impressively expanding the SUSE Ecosystem. The key consideration around StackState is that it stretches out observability to include database, endpoints, message queues, and more – not just the Kubernetes setup.

From the Linux distributions, to managing and handling container workloads with Rancher, to Zero-trust security tools adding attack detection and protection with NeuVector, to Harvester that handles VM workloads along with containers, StackState covers it all ! Its observability capabilities are purely impressive.

This StackState platform will most probably be integrated into Rancher Prime at first, and we truly hope that it will also be available as an Open Source solution later on.

Liberty Linux and SUSE AI were also presented during the Keynotes.

SUSE provides a complete ecosystem for running VM and containers workload in the Cloud or On-Prem as Open Source with the possibility to get extended support and capability through the PRIME offering !

The Keynote was focusing on the following 4 main axes:

• Linux
• Cloud Native
• Edge
• AI

During the last day of the keynote, we got an overview of the latest innovations on SUSE Linux : a new Linux kernel is being introduced.
Additionally, SUSE will extend its Linux support, thus becoming the vendor to propose the longest support period in the industry.

Harvester was also in front of the announcement : It does not intent to become a replacement of VMWare but an alternative for those who already did the choice to modernise their Platform, bridging Virtualisation and Cloud Native (Running VM along with containers workload is where Harvester is coming into the picture).

Few figures have been presented to us, SUSE ecosystem is impressive and it will continue to grow :

• SUSE’s 30 years of Open-Source Solution counts more than 50’000 active Rancher users
• more than 10 millions downloads of K3s monthly,
• 68% of Harvester YoY growth and download growth
• more than 125’000 Longhorn managed nodes

Latest updates and information about the Kubernetes Landscape and Rancher Prime 3.1 update :

Summary of the most interesting technical sessions I followed

The DEMOPALOOZA.

During the last session we followed before leaving, we could participate into a fun presentation on SUMA, Rancher, AI, Harvester, etc

It was presented in a playful way, with role play simulating crash and restoration of linux state, presenting capabilities of the SUSE AI solution and so on.

Really interesting way to conclude the SUSECON with a touch of humor.

Multi-tier management and observability of Edge clusters with Rancher

Edge clusters

During this session, the edge computing was explained and shoewed that the next challenge will be to manage very large scale infrastructures and observe more and more clusters, not only hundreds but it will soon become tenth of thousands of clusters.
The limits are pushed beyond what a single Rancher manager can currently handle. High quality and user experience must be kept in mind for maintaining clusters at large scale, focused on observability. For that purpose, Hub Rancher Cluster is a new feature that will allow to manage a set of spoke clusters where multiple downstream clusters will be attached. The Hub Rancher will receive aggregated information from each Spoke’s Downstream clusters and Grafana dashboard will allow to display overall information about the health of downstream clusters. A “drill down” capability is implemented to have a detailed overview of the whole edge platform of a company. Grafana Mimir is used to store all this data and present them in a consolidated dashboard view.

This feature is not yet available. It should be rolled out soon!

Cloud-Native Software Virtual Machines

I really liked this session as it was about Software Virtual Machine such as the JVM, the eBPF program and WebAssembly. The speaker explained what’s really behind this concept, its origins, and describing eBPF, WebAssembly and Edge applications at a high level. This really shows the evolution of the Software Virtual Machine since the beginning till today, showing that eBPF and WebAssembly will be the perfect match.

Deep Dive into the SUSE Customer Centre, RMT and SUSE Registry

The last technical session I followed was about the value of subscribing to SUSE, the key take aways were the following:

• Trusted open-source supply chain
• Linux, infrastructure and container management
• Maintenance and security updates
• Documentation & knowledge base
• Technical support

The trusted official SUSE container image provides several benefits:

• Easy discovery
• Rich information
• Vulnerability reports
• Image documentation
• Search and filtering
• Access exclusive subscriber-only content

A self-hosted, supported container image and OCI artifact repository can also be deployed On-Prem without external access requirements when pulling image from a Kubernetes cluster.

The benefits of this private registry are:

• Designed to work with the entire SUSE portfolio
• Host official SUSE images and helm charts, as well as your own
• Role-based access control
• Vulnerability scans

Thanks to the organiser of the event as well as the SUSE employees. I had the chance to discuss with some of them outside, during the party or when taking break between the sessions !

L’article The SUSECON 2024 in Berlin est apparu en premier sur dbi Blog.