Thomas-Krenn-Wiki - Neue Seiten [de-formal]

SNMP im TKMI aktivieren und konfigurieren

2026-04-20T08:19:47Z

Azillner: Erstellung des Artikels: SNMP im TKMI aktivieren und konfigurieren

Dieser Artikel beschreibt, wie Sie im TKMI (Thomas-Krenn Management Interface) den ''' SNMP-Zugriff''' für einen Benutzer aktivieren und konfigurieren.

== Voraussetzungen ==

Ein kompatibler TKMI bzw. Thomas-Krenn Server
Zugriff auf die TKMI/IPMI-Weboberfläche
Gültige Benutzeranmeldedaten mit administrativen Rechten

== Benutzerverwaltung ==

Damit SNMP genutzt werden kann, muss der Zugriff zunächst für einen Benutzer im TKMI aktiviert werden.

<gallery mode="nolines" widths="300" heights="300">
TKMI-SNMP-User_Login.png|Anmeldung an der TKMI-Weboberfläche mit einem gültigen Benutzer (z. B. ''admin'').
TKMI-SNMP-Dashboard.png|Nach der Anmeldung im linken Menü auf '''Settings''' wechseln.
TKMI-SNMP-Settings.png|Im Bereich '''Settings''' den Punkt '''User Management''' öffnen.
TKMI-SNMP-User_Management.png|Den gewünschten Benutzer auswählen, für den SNMP aktiviert werden soll.
TKMI-SNMP-User_Logged_In_Password.png|Das aktuell verwendete Passwort im Feld '''Logged-In Password''' zur Bestätigung eingeben.
TKMI-SNMP-User_SNMP_Activate.png|Im unteren Bereich '''SNMP Access''' aktivieren und die gewünschten SNMP-Parameter setzen.
</gallery>

Nach der Konfiguration müssen die Änderungen mit '''Save''' gespeichert werden.

== MIB Browser ==

Zur Überprüfung der SNMP-Erreichbarkeit und zum Auslesen von Werten kann ein MIB Browser verwendet werden.

In diesem Beispiel wird der '''iReasoning MIB Browser''' genutzt.

<gallery mode="nolines" widths="100" heights="100">
Download.png| iReasoning MIB Browser download
</gallery>

== Verbindung zum TKMI herstellen ==

Nach der Aktivierung von SNMP im TKMI kann die Verbindung wie folgt getestet werden:

<gallery mode="nolines" widths="300" heights="300">
TKMI-SNMP_MIB_Browser.png|Im Feld '''Address''' die IP-Adresse des TKMI eintragen. Über '''Advanced...''' gelangt man in die erweiterten SNMP-Einstellungen.
TKMI-SNMP-MIB_Browser_Settings.png|In den erweiterten Einstellungen '''SNMP Version 3''' auswählen und die Zugangsdaten setzen.
TKMI-SNMP-MIB_Browser_Test.png|Nach der Konfiguration kann über '''Go''' eine Abfrage gestartet werden. Erfolgreiche Antworten werden in der '''Result Table''' angezeigt.
</gallery>

== Wichtige Einstellungen (SNMPv3) ==

Für eine erfolgreiche Verbindung müssen die folgenden Parameter mit den im TKMI gesetzten Werten übereinstimmen:

'''Address:''' IP-Adresse des TKMI
'''Port:''' 161
'''SNMP Version:''' 3
'''User:''' Entspricht dem im TKMI konfigurierten Benutzer
'''Security Level:''' authPriv
'''Auth Algorithm:''' z. B. SHA256
'''Auth Password:''' gesetztes Authentifizierungs-Passwort
'''Privacy Algorithm:''' z. B. DES
'''Privacy Password:''' gesetztes Verschlüsselungs-Passwort

'''Hinweis:'''
Abweichungen bei Benutzername, Passwort oder Algorithmen führen dazu, dass keine SNMP-Antworten zurückgeliefert werden.

== Testabfrage ==

Für einen einfachen Funktionstest kann folgende OID verwendet werden:

'''1.3.6.1.2.1.1.1.0''' (sysDescr)

Bei erfolgreicher Verbindung wird eine Systembeschreibung des TKMI in der '''Result Table''' angezeigt.

== Troubleshooting ==

Falls der SNMP-Zugriff nicht funktioniert:

'''SNMP Access nicht aktiviert'''
'''Falsche Zugangsdaten / Community'''
'''Firewall blockiert SNMP (Port 161/UDP)'''
'''Falsche OID angegeben'''
'''SNMP-Version stimmt nicht überein'''

Autor: Adrian Zillner

Adrian Zillner ist im Technical Service bei der Thomas-Krenn AG tätig. Er ist für das Betreuen von Kunden und Beantworten von Fragen bei technischen Problemen zuständig.

AMD Sicherheitslücken - April 2026

2026-04-17T06:35:28Z

Aranzinger:

Am '''14. April 2026''' wurden von AMD die Security Bulletins '''AMD-SB-7054'''<ref>Incorrect use of LocateProtocol Service of the EFI_BOOT_Services table in SMI Handler – April 2026 (www.amd.com/en/resources/product-security)</ref>, '''AMD-SB-3034'''<ref>SEV-SNP Routing Misconfiguration – April 2026 (www.amd.com/en/resources/product-security)</ref> und '''AMD-SB-3016'''<ref>IOMMU Write Buffer Vulnerability – April 2026 (www.amd.com/en/resources/product-security)</ref> mit jeweils einer Sicherheitslücke veröffentlicht. Dieser Artikel beinhaltet Tabellen mit Maßnahmen zur Behebung der Sicherheitslücken.

== Betroffene Systeme ==

'''AMD Threadripper Systeme:'''

Systeme mit AMD Ryzen Threadripper PRO 3000WX Prozessoren
Systeme mit AMD Ryzen Threadripper PRO 5000WX Prozessoren
Systeme mit AMD Ryzen Threadripper 7000 / PRO 7000WX Prozessoren
Systeme mit AMD Ryzen Threadripper 9000 / PRO 9000WX Prozessoren

'''AMD EPYC Systeme:'''

Systeme mit "Zen 4" AMD EPYC 4004 Raphael Prozessoren
Systeme mit "Zen 2" AMD EPYC 7002 Rome Prozessoren
Systeme mit "Zen 3" AMD EPYC 7003 Milan Prozessoren
Systeme mit "Zen 4" AMD EPYC 9004 Genoa und Bergamo & 8004 Siena Prozessoren
Systeme mit "Zen 5" AMD EPYC 9005 Turin Prozessoren

== Problemlösung ==

Hier eine tabellarische Aufstellung der entsprechenden CVEs und Maßnahmen zur Behebung, für die jeweilige EPYC Generation, falls vorhanden.

'''AMD EPYC 4004 Raphael'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2025-54502	7.1 (Hoch)	ComboAM5PI 1.0.0.d (2025-11-12)

'''AMD EPYC 7002 Rome'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2025-54502	7.1 (Hoch)	RomePI 1.0.0.P (2025-11-04)

'''AMD EPYC 7003 Milan:'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	TCB‑Wert für die SEV‑Attestierung	TCB‑Wert für die SNP‑Attestierung
CVE-2025-54502	7.1 (Hoch)	MilanPI 1.0.0.J (2025-12-15)	N/A	N/A	N/A
CVE-2025-54510	5.9 (Mittel)	MilanPI 1.0.0.J (2025-12-15)	N/A	TCB[SNP]>=0x1D mitigation bit = 4	N/A
CVE-2023-20585	5.6 (Mittel)	MilanPI 1.0.0.H (2025-09-04) + OS Update	SEV FW 1.37.23 + OS Update	N/A	TCB[SNP]>=0x1B

'''AMD EPYC 8004 Siena:'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	TCB‑Wert für die SEV‑Attestierung	TCB‑Wert für die SNP‑Attestierung
CVE-2025-54502	7.1 (Hoch)	GenoaPI 1.0.0.H (2025-12-15)	N/A	N/A	N/A
CVE-2025-54510	5.9 (Mittel)	GenoaPI 1.0.0.H (2025-12-15)	N/A	TCB[SNP]>=0x1C	N/A
CVE-2023-20585	5.6 (Mittel)	GenoaPI_1.0.0.G (2025-06-27) + OS Update	SEV FW 1.37.31 + OS Update	N/A	TCB[SNP]>=0x1B

'''AMD EPYC 9004 Genoa:'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	TCB‑Wert für die SEV‑Attestierung	TCB‑Wert für die SNP‑Attestierung
CVE-2025-54502	7.1 (Hoch)	GenoaPI 1.0.0.H (2025-12-15)	N/A	N/A	N/A
CVE-2025-54510	5.9 (Mittel)	GenoaPI 1.0.0.H (2025-12-15)	N/A	TCB[SNP]>=0x1C	N/A
CVE-2023-20585	5.6 (Mittel)	GenoaPI_1.0.0.G (2025-06-27) + OS Update	SEV FW 1.37.31 + OS Update	N/A	TCB[SNP]>=0x1B

'''AMD EPYC 9005 Turin / Turin Dense'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	TCB‑Wert für die SEV‑Attestierung	TCB‑Wert für die SNP‑Attestierung
CVE-2025-54502	7.1 (Hoch)	TurinPI 1.0.0.9 (2025-12-31)	N/A	N/A	N/A
CVE-2025-54510	5.9 (Mittel)	TurinPI 1.0.0.8 (2025-11-26)	N/A	TCB[SNP]>=0x5	N/A

'''Tabelle der von CVE-2025-54502 betroffenen Threadripper Prozessoren:'''


CPU	'''AGESA Version'''
AMD Ryzen Threadripper PRO 3000WX	ChagallWSPI-sWRX8 1.0.0.D (2025-11-04) CastlePeakWSPI-sWRX8 1.0.0.I (2025-10-17)
AMD Ryzen Threadripper PRO 5000WX	ChagallWSPI-sWRX8 1.0.0.D (2025-11-04)
AMD Ryzen Threadripper 7000	ShimadaPeakPI-SP6 1.0.0.1c (2025-10-21)
AMD Ryzen Threadripper PRO 7000WX	ShimadaPeakPI-SP6 1.0.0.1c (2025-10-21) StormPeakPI-SP6 1.0.0.1m (2025-12-01) StormPeakPI-SP6_1.1.0.0k (2025-12-01)
AMD Ryzen Threadripper 9000	ShimadaPeakPI-SP6 1.0.0.1c (2025-10-21)
AMD Ryzen Threadripper PRO 9000WX	ShimadaPeakPI-SP6 1.0.0.1c (2025-10-21)

Supermicro Security Bulletins zu den Sicherheitslücken veröffentlicht. Eine Liste mit BIOS-Versionen der jeweiligen Mainboards, um die Lücken zu schließen, ist auch enthalten. Nachfolgend ein Auszug aus dieser Tabelle, in der alle Mainboards aufgeführt sind, die von Thomas Krenn angeboten werden: <ref>Supermicro Security Center (www.supermicro.com)</ref>


AMD Motherboard	'''BIOS Version'''
H12SSW-iN/NT	3.6
H12SSL-i/C/CT/NT	3.6
H12DSi-N6/NT6	3.6
H13SSW	3.9
H13SSL-N/NC	3.9

=== Updates für Produkte von Thomas-Krenn ===
Updates zum jeweiligen System finden Sie im <tklink type="sitex" id="440">Downloadbereich von Thomas-Krenn</tklink>.
Die Versionen im Downloadbereich wurden von uns getestet, um die Stabilität und Kompatibilität unserer Systeme zu gewährleisten.

Falls Sie die aktuellste Version für ihr System benötigen und diese noch nicht bei uns im Downloadbereich zu finden ist, können Sie diese im Downloadbereich bei Asus oder Supermicro beziehen.

== Einzelnachweise ==
<references/>

Autor: Thomas-Krenn.AG

Bei der Thomas-Krenn.AG achten wir auf den bestmöglichen Service. Um dem gerecht zu werden, haben wir unser Thomas-Krenn Wiki ins Leben gerufen. Hier teilen wir unser Wissen mit Ihnen und informieren Sie über Grundlagen und Aktuelles aus der IT-Welt. Ihnen gefällt unsere Wissenskultur und Sie wollen Teil des Teams werden? Besuchen Sie unsere Stellenangebote.

Windows Secure Boot Zertifikat Ende der Gültigkeit

2026-04-17T06:09:30Z

Aranzinger:

In diesem Wiki-Artikel zeige ich Ihnen, wie sie das Secure Boot Zertifikat auslesen können.

Die bisherigen Zertifikate wurden 2011 ausgestellt, welche dieses Jahr auslaufen.

== Welche Zertifikate sind betroffen? ==
Begriffserklärung:

'''KEK:''' Key Enrollment Key
'''CA:''' Certificate Authority
'''DB:''' Secure Boot Signature Database
'''DBX:''' Secure Boot Revoked Signature Database

Übersichts-Tabelle
Auslaufende Zertifikate	Auslauf Datum	Neues Zertifikat	Speicherort	Zweck
'''Microsoft Corporation KEK CA 2011'''	Juni 2026	Microsoft Corporation KEK 2K CA 2023	Im KEK gespeichert	Signiert Updates für DB und DBX.
'''Microsoft Windows Production PCA 2011'''	Okt 2026	Windows UEFI CA 2023	In Datenbank gespeichert	Wird zum Signieren des Windows-Startladeprogramms verwendet.
'''Microsoft UEFI CA 2011''*'''''	Juni 2026	Microsoft UEFI CA 2023	In Datenbank gespeichert	Signiert Startladeprogramme von Drittanbietern und EFI-Anwendungen.
'''Microsoft UEFI CA 2011''*'''''	Juni 2026	Microsoft Option ROM UEFI CA 2023	In Datenbank gespeichert	Signiert Option-ROMs von Drittanbietern

<nowiki>*</nowiki>Während der Verlängerung des Microsoft Corporation UEFI CA 2011-Zertifikats trennen zwei Zertifikate die Bootloadersignatur von der Option-ROM-Signatur.

Dies ermöglicht eine präzisere Kontrolle über die Systemvertrauensstellung. Systeme, die Option-ROMs vertrauen müssen, können z. B. die Microsoft Option ROM UEFI CA 2023 hinzufügen, ohne dass für Startladeprogramme von Drittanbietern eine Vertrauensstellung hinzugefügt wird.

== Was sind die Auswirkungen wenn mein Zertifikat ausläuft? ==

Windows startet und funktioniert weiterhin wie gewohnt. Auch Updates können weiterhin heruntergeladen und installiert werden.

Jedoch können keine Updates für den frühen Boot Prozess installiert werden. Das betrifft den Windows Boot Manager, Secure Boot Datenbanken, Revocation Listen oder Behebungen für neu entdeckte Boot Level Schwachstellen.

Diese Auswirkungen reduzieren den Schutz der Geräte vor kommenden Gefahren, welche auf Secure Boot vertrauen wie Bitlocker Hardening oder Bootloader von Drittanbietern.

== Wie prüfe ich meine Zertifikate? ==

Die Gültigkeit der installierten Zertifikate kann über die Windows Sicherheits-App geprüft werden.

'''Windows-Sicherheit > Gerätesicherheit > Sicherer Start'''

Hier gibt es drei Mögliche Szenarien.

=== Szenario 1: Alles ist vollständig aktualisiert (Grüner Haken) ===
Alle Zertifikatsupdates wurden angewendet.

=== Szenario 2: Es wurde noch kein Update eingespielt (Gelbes Warnsymbol) ===
Es wird keine Automatische Aktualisierung ermöglicht. Man muss sich an den Hardware Hersteller wenden.

=== Szenario 3: Eingreifen ist erforderlich (Rotes X) ===
Das Gerät kann keine erforderlichen Updates empfangen.

Bei einem Fehlenden Windows Update kann es passieren, dass dieser Menüpunkt keinen Hinweis auf die Zertifikate liefert.

In diesem Fall kann das Zertifikat mit einem Workaround auch manuell ausgelesen werden.

Mit folgenden PowerShell Befehl lassen sich die Zertifikate als .bin an einem Beliebigen Speicherort sichern.<syntaxhighlight lang="powershell">
$var = Get-SecureBootUEFI -Name db; [System.IO.File]::WriteAllBytes("C:\Users\Administrator\Documents\db.bin", $var.Bytes)
</syntaxhighlight>Der Pfad lässt sich beliebig anpassen.

Anschließend muss die db.bin Datei auf einem Linux System (z.B. WSL) mit den efitools auf die Zertifikate aufgeteilt werden.<syntaxhighlight lang="bash">
sudo apt update && apt install efitools
sudo sig-list-to-certs db.bin cert
</syntaxhighlight>

Jetzt sollten 5 Zertifikate im aktuellen Verzeichnis erstellt worden sein: cert-0.der cert-1.der cert-2.der cert-3.der cert-4.der

Den Inhalt dieser Zertifikate kann man mit Openssl auslesen.<syntaxhighlight lang="bash">
openssl x509 -in cert-0.der -inform DER -text -noout
</syntaxhighlight>
Wobei der Datei Name "cert-0.der" an das jeweilige Zertifikat angepasst werden muss.

Wichtig hierbei ist die Zeile Validity. Zeigt diese den folgenden Wert an, läuft das Zertifikat im Juni 2026 aus:

Validity

Not Before: Jun 27 21:22:45 2011 GMT

Not After : Jun 27 21:32:45 2026 GMT

== Wie aktualisiere ich meine Zertifikate? ==

Es gibt mehrere Wege das Zertifikat zu aktualisieren. Die einfachste und Beste Methode erfolgt über ein BIOS Update, wobei der Hardware Hersteller die neuen Zertifikate bereits integriert hat.

== Einzelnachweise ==

Windows Secure Boot certificate expiration and CA updates (support.microsoft.com)
Windows Secure Boot Key Creation and Management Guidance (learn.microsoft.com)
IT admin guide: Secure Boot certificate update status in the Windows Security app (support.microsoft.com)

Autor: Bastian Stockinger

Bastian Stockinger arbeitet im Product Management Team von Thomas-Krenn. Nach seiner Ausbildung zum Fachinformatiker für Systemintegration betreute er Netzwerk- und Storage Hardware. 2024 Spezialisierte er sich als Solutions Engineer auf den Bereich Storage Lösungen für TrueNAS, Open-E JovianDSS, Microsoft S2D & Azure Local. In seiner Freizeit ist er gern in den Bergen wandern und engagiert sich in der Freiwilligen Feuerwehr.

Q-Feeds Webinterface und Lizenz aktivieren

2026-04-15T14:59:05Z

Aranzinger:

Das Cybersecurity Plugin Q-Feeds bietet eine Cloud-Plattform mit vielfältigen Informationen an. Hiermit können auch Lizenzen zum eigenen Account hinzugefügt und Token für Geräte wie OPNsense-Firewalls erzeugt werden. Dieser Artikel zeigt wie Sie unter der '''Q-Feeds Threat Intelligence Platform v2.3''' eine '''Lizenz hinzufügen''' und einen '''Token für Ihre Firewall erstellen''' können.

Hier geht es zu den Q-Feeds Connect Lizenzen im Onlineshop von Thomas-Krenn

== Anmelden bei der Cloud Plattform ==
Melden Sie sich bei tip.qfeeds.com an, oder erstellen Sie einen neuen Account.

== Q-Feeds Dashboard ==
Nun wird das Q-Feeds Dashboard nach erfolgreichem Login angezeigt.

== Lizenzen hinzufügen und verwalten ==
Dieser Abschnitt zeigt wie Sie eine Lizenz aktivieren und Ihrem Account hinzufügen.

<gallery>
File:Q-Feeds-Webinterface-003.png|Klicken Sie rechts oben auf Ihren ''Accountnamen'' und anschließend im Dropdown Menü auf ''Licenses''.
File:Q-Feeds-Webinterface-004.png|Klicken Sie anschließend rechts oben auf die Schaltfläche ''Activate License''. Es erscheint dann dieses Menü, geben Sie den Lizenzschlüssel an und klicken Sie auf ''Activate License''.
File:Q-Feeds-Webinterface-005.png|Die Lizenz ist hinzugefügt und aktiv.
</gallery>

== API Key für Endgeräte wie OPNsense Firewalls erstellen ==
Dieser Abschnitt zeigt wie Sie API Keys für ihre OPNsense Firewall erstellen. Ein solcher Key ist für das Q-Feeds Plugin bei der OPNsense Firewall erforderlich.

<gallery>
File:Q-Feeds-Webinterface-006.png|Klicken Sie im Dashboard links unten auf ''Account Settings'', anschließend auf den Reiter ''API KEYS''. Mit dem Button Add API Key können Sie nun einen Key ergänzen. Geben Sie eine Beschreibung an und wählen Sie bei dem Feld '''Assign License''' eine gültige Lizenz an. Klicken Sie auf ''Save Key''.
File:Q-Feeds-Webinterface-007.png|Der API Token erscheint. Kopieren Sie ihn und fügen Sie ihn bei der OPNsense-Firewall im Q-Feeds Plugin ein.
</gallery>

Autor: Thomas Niedermeier

Thomas Niedermeier arbeitet im Product Management Team von Thomas-Krenn. Er absolvierte an der Hochschule Deggendorf sein Studium zum Bachelor Wirtschaftsinformatik. Seit 2013 ist Thomas bei Thomas-Krenn beschäftigt und kümmert sich unter anderem um OPNsense Firewalls, das Thomas-Krenn-Wiki und Firmware Sicherheitsupdates.

Q-Feeds Connect Einrichtung unter OPNsense 26.1

2026-04-07T13:21:46Z

Aranzinger:

Die Open Source Firewall OPNsense kann durch eine Integration der Q-Feeds Firewall Blocklisten und DNS Filter Regeln mit den neuesten Bedrohungsinformationen aufgewertet werden. Dieser Artikel zeigt wie Sie unter '''OPNsense 26.1''' das '''Q-Feeds Connect Plugin installieren, die Firewall Regeln''' und '''Unbound DNS Filter Regeln''' anlegen.

Hier geht es zu den Q-Feeds Connect Lizenzen im Onlineshop von Thomas-Krenn

== Q-Feeds Connect Plugin ==
Das Q-Feeds Connect Plugin kann bequem als Plugin bei OPNsense installiert werden.

=== Installation des Plugins ===
<gallery>
File:OPNsense-Q-Feeds-001.png|Gehen Sie zu ''System → Firmware → Plugins''.
File:OPNsense-Q-Feeds-002.png|Das Plugin "os-q-feeds-connector" ist im OPNsense Repository gepflegt und kann direkt installiert werden. Klicken Sie zur Installation auf das '''+'''.
File:OPNsense-Q-Feeds-003.png|Q-Feeds Connect wurde installiert.
File:OPNsense-Q-Feeds-004.png|Klicken Sie auf den Knopf zum Neuladen des Browsers.
</gallery>

=== Konfiguration des Plugins ===
Das Plugin wurde installiert und nun kann die Konfiguration vorgenommen werden.
<gallery>
File:OPNsense-Q-Feeds-005.png|Klicken Sie auf den neuen Menüpunkt ''Security''.
File:OPNsense-Q-Feeds-006.png|Anschließend auf ''Q-Feeds Connect''.
File:OPNsense-Q-Feeds-007.png|Im Reiter Settings werden die Einstellungen gesetzt.
File:OPNsense-Q-Feeds-008.png|Geben Sie Ihren API-Key an. Setzen Sie den Haken bei '''Register domain feeds''', um die Unbound DNS Blocklisten von Q-Feeds zu aktivieren. Klicken Sie anschließend auf ''Apply''.
File:OPNsense-Q-Feeds-009.png|Im Reiter '''Feeds''' werden die geladenen IP-Adressen und Domainnamen aufgelistet.
File:OPNsense-Q-Feeds-010.png|Reiter Events
</gallery>

=== Firewall Maximum Table Entries Anpassungen ===
Optional können Sie die Maximalzahl der Firewall Maximum Table Entries anpassen.

<gallery>
File:OPNsense-Q-Feeds-011.png|Wechseln Sie zum Menü ''Firewall → Settings → Advanced'' und scrollen zur Zeile '''Firewall Maximum Table Entries'''. Passen Sie den Standardwert gegebenenfalls an.
File:OPNsense-Q-Feeds-012.png|Die aktuelle Anzahl an Einträgen können Sie im Menü ''Firewall → Aliases'' betrachten.
File:OPNsense-Q-Feeds-013.png|Ein Q-Feeds Alias Eintrag wurde angelegt.
</gallery>

== Q-Feeds Firewall Regel Konfiguration ==
Nach der Installation und Konfiguration des Plugins können nun die Firewall Regeln gesetzt werden. In diesem Beispiel wird die Q-Feeds Blockliste auf LAN und WAN Schnittstelle aktiviert.

=== Blockregel ausgehender Traffic LAN Interface ===
Für eine LAN Schnittstelle bietet sich eine Regel an, die LAN eingehend jeglichen Traffic zu Zielen, die in der Blockliste enthalten sind, blockiert.

<gallery>
File:OPNsense-Q-Feeds-029.png|Gehen Sie zum Menü Firewall → Rules [new] und klicken Sie auf das '''+'''.
File:OPNsense-Q-Feeds-030.png|Geben Sie eine Beschreibung an und weisen Sie der Regel das Interface '''LAN''' zu.
File:OPNsense-Q-Feeds-031.png|Bei Action wählen Sie ''Block''.
File:OPNsense-Q-Feeds-032.png|Destination ist der Alias '''__qfeeds_malware_ip'''.
File:OPNsense-Q-Feeds-033.png|Klicken Sie auf ''Save''.
File:OPNsense-Q-Feeds-034.png|Aktivieren Sie die Checkbox vor der neuen Regel und klicken Sie auf den Pfeil bei der Allow from LAN Regel. Somit wird die Block-Regel vor der Allow-Regel abgearbeitet.
File:OPNsense-Q-Feeds-035.png|Klicken Sie auf '''Apply'''.
</gallery>

=== Blockregel eingehender Traffic WAN Interface ===
Für eine WAN Schnittstelle bietet sich eine Regel an, die WAN eingehend jeglichen Traffic von Quell-IPs, die in der Q-Feeds Blockliste enthalten sind, blockiert.

<gallery>
File:OPNsense-Q-Feeds-036.png|Gehen Sie zum Menü Firewall → Rules [new] und klicken Sie auf das '''+'''.
File:OPNsense-Q-Feeds-037.png|Geben Sie eine Beschreibung an und weisen Sie der Regel das Interface '''WAN''' zu.
File:OPNsense-Q-Feeds-038.png|Bei Action wählen Sie ''Block''.
File:OPNsense-Q-Feeds-039.png|Source ist der Alias '''__qfeeds_malware_ip'''.
File:OPNsense-Q-Feeds-040.png|Klicken Sie auf ''Save''.
File:OPNsense-Q-Feeds-041.png|Aktivieren Sie die Checkbox vor der neuen Regel und klicken Sie auf den Pfeil bei der Allow from WAN net Regel. Somit wird die Block-Regel vor der Allow-Regel abgearbeitet.
File:OPNsense-Q-Feeds-042.png|Klicken Sie auf '''Apply'''.
</gallery>

== Weitere Einstellungen zum Unbound DNS ==
Bei Q-Feeds Plus (nur OSINT) und Premium (OSINT und Paid) können Sie zusätzlich auch DNS Anfragen mit dem Unbound DNS filtern. Die DNS Filter Regeln werden automatisch aktiviert.
<gallery>
File:OPNsense-Q-Feeds-027.png|Sie können das Unbound DNS reporting aktivieren, klicken Sie hier auf ''Reporting → Settings'' und erlauben Sie die lokale Sammlung von Statistiken beim Unbound. Klicken Sie auf ''Save''.
File:OPNsense-Q-Feeds-028.png|Die Größe der Blocklist wird nun angezeigt.
</gallery>

Autor: Thomas Niedermeier

Q-Feeds Versionen Featurevergleich

2026-04-07T13:17:33Z

Aranzinger:

Next-Generation-Firewalls (NGFWs) sind wichtige Werkzeuge zum Schutz der Netzwerke. Sie können DNS- und Web-Datenverkehr anhand externer dynamischer Listen mit Bedrohungsindikatoren, sogenannten Indicators of Compromise (IoCs), filtern. Q-Feeds stellt dynamische, aktuelle Listen dieser IoCs bereit, die speziell für den Einsatz mit Sicherheitskontrollen wie NGFWs entwickelt wurden. Durch die Möglichkeit Q-Feeds als Plugin bei OPNsense-Firewalls zu ergänzen kann man die Schutzfunktion vor neuen und aufkommenden Bedrohungen verbessern. Das bedeutet, dass OPNsense mit den neuesten Bedrohungsinformationen auf dem Laufenden bleiben kann, um schädlichen Datenverkehr zu filtern. Dieser Artikel zeigt die '''verschiedenen Q-Feeds Lizenzen''' mit ihren Features '''tabellarisch dargestellt zum Vergleich''' auf.

Hier geht es zu den Q-Feeds Connect Lizenzen im Onlineshop von Thomas-Krenn

== Q-Feeds Versionen ==
Diese Tabelle zeigt die drei Q-Feeds Lizenzen mit ihren Eigenschaften und Unterschieden auf.

Q-Feeds Versionen Eigenschaften und Unterschiede
	Feature	Community Edition	Plus	Premium
Services	Active Support	-	✔	✔
Easy Integration	✔	✔	✔
Curated data	✔	✔	✔
Update frequency	delayed by 7 days	delayed by 4 hours	every 20 minutes
IoC (indicators of compromise) lookup	-	✔	✔
EASM (External Attack Service Management)	-	1 scan per week	1 scan per day
Dark web monitoring	-	✔	✔
Brand Protection	-	-	✔
OSINT (Open-Source Intelligence)	IP	✔	✔	✔
DNS	✔	✔	✔
Paid	IP	-	✔	✔
DNS	-	-	✔

Autor: Thomas Niedermeier

Backup und Restore unter Debian 13 mit Proxmox Backup Client

2026-03-25T07:16:16Z

Aranzinger:

Dieser Artikel beschreibt, wie Sie ein '''Debian 13''' System mit Hilfe des '''Proxmox Backup Clients''' auf den Proxmox Backup Server sichern können.

== Ausgangssituation ==
Sie benötigen für die Ausführung einen '''Proxmox Backup Server''' und ein '''Debian 13''' System, welches Sie sichern möchten.

Wenn Sie noch '''keinen PBS installiert''' haben, finden Sie hier eine Anleitung zur Installation: Proxmox Backup Server Installation.

== Proxmox Backup Client ==
In diesem Abschnitt wird der '''Proxmox Backup Client''' auf dem Debian 13 System installiert und konfiguriert.

Die komplette Installation wird als '''root User''' durchgeführt. Mit folgenden Befehl kann sich als Root-User angemeldet werden: <pre>su</pre>

=== Repository hinzufügen ===
Als Erstes muss das '''Repository''' für den ''Proxmox Backup Client'' konfiguriert werden. Dazu muss die Datei ''proxmox-backup-client.list'' mit folgendem Befehl erstellt werden:
<pre>sudo nano /etc/apt/sources.list.d/proxmox-backup-client.list</pre>
In diese Datei muss folgender Inhalt übernommen werden:
<pre>deb http://download.proxmox.com/debian/pbs-client trixie main</pre>
Als Nächstes muss der '''Repository-GPG-Key''' importiert werden. Proxmox verwendet für jede Debian-Version einen anderen GPG-Key. Für Debian Version 13 wird der GPG-Key für Trixie benötigt:
<pre>wget -qO - https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg | sudo tee /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg >/dev/null</pre>

=== Installation ===
Nach der Einrichtung des ''Proxmox Backup Client'' Repository müssen alle Paketlisten aktualisiert werden:<pre>
sudo apt update</pre>
Jetzt können sie den ''Proxmox Backup Client'' installieren:
<pre>sudo apt install proxmox-backup-client</pre>

=== Verbindung mit PBS herstellen ===
Nach erfolgreicher Installation des Clients können Sie sich mit folgendem Befehl mit dem Proxmox Backup Server verbinden:
<pre>proxmox-backup-client login --repository <user>@<pam>@<ipadresse>:<datastore></pre>
Folgende Anpassungen müssen hierbei durchgeführt werden:

<code><user></code>: Den Nutzernamen des PBS angeben, wir empfehlen hier nicht root zu nutzen, sondern einen alternativen Account mit den benötigten Berechtigungen
<code><pam></code>: Hier wird der Realm eingetragen der bei der Anmeldung beim PBS benötigt wird (meist ist dieser '''pam''')
<code><ipadresse></code>: Hier die IP Adresse des Proxmox Backup Servers eintragen
<code><datastore></code>: Den Namen des Datastores angeben auf welchen die Backups gesichert werden sollten
'''Der Eintrag könnte so aussehen: "backup@pam@10.26.33.11:zfs-pool".'''

Dann den Fingerprint akzeptieren und das Passwort des PBS eingeben.

Jetzt ist der Backup-Client fertig auf Ihrem Debian System installiert.

== Backup durchführen ==

=== Art der Sicherung ===
Wenn Sie eine Datei oder einen Pfad sichern möchten, führen Sie folgenden Befehl aus:
<pre>proxmox-backup-client backup etc.pxar:/(Verzeichnis oder Datei, das Sie Sichern möchte) --repository <user>@<pam>@<ipadresse>:<datastore></pre>
Wenn Sie das komplette System sichern möchten, benötigen Sie diesen Befehl:
<pre>proxmox-backup-client backup etc.pxar:/ --repository <user>@<pam>@<ipadresse>:<datastore></pre>
Nachdem Sie einen der Befehle ausgeführt haben, sollte das Backup nun im Datastore des Proxmox Backup Servers angezeigt werden.

=== Anzeige in der Shell ===
Sie können die Backups in der Debian Shell anzeigen lassen:<pre>proxmox-backup-client snapshots --repository <user>@<pam>@<ipadresse>:<datastore></pre>
Beispiel Output:<pre>
┌──────────────────────────────────┬───────┬───────────────────────────────────┐
│ snapshot │ size │ files │
╞══════════════════════════════════╪═══════╪═══════════════════════════════════╡
│ host/debian/2026-03-11T11:33:16Z │ 728 B │ catalog.pcat1 etc.pxar index.json │
└──────────────────────────────────┴───────┴───────────────────────────────────┘
</pre>

== Restore ==
Für die Wiederherstellung Ihrer Daten führen Sie folgenden Befehl aus:<pre>proxmox-backup-client restore <Backup Name> etc.pxar <Zielverzeichnis> --repository <user>@<pam>@<ipadresse>:<datastore></pre>

<code><Backup Name></code>: Geben Sie den vollständigen Namen des Backups an
<code><Zielverzeichnis></code>: Geben Sie hier das Zielverzeichnis für die Wiederherstellung an
<code><user>, <pam>, <ipadresse>, <datastore></code>: Diese sind so zu wählen, wie bei Verbindung mit PBS angegeben

=== Beispiel ===
Für das Beispiel nutzen wir folgende Werte:

'''Backup Name''': <code>host/debian/2026-03-11T11:33:16Z</code>
'''Zielverzeichnis''': <code>/home</code>
'''user''': <code>backup</code>
'''pam''': <code>pam</code>
'''ip-adresse''': <code>10.21.0.50</code>
'''datastore''': <code>backup_ssd</code>

Das ergibt folgenden Befehl:<pre>proxmox-backup-client restore host/debian/2026-03-11T11:33:16Z etc.pxar /home --repository backup@pam@10.21.0.50:backup_ssd</pre>

== Cron-Job ==
Sie können Ihre Sicherungen auch mithilfe eines '''Cron-Jobs''' automatisieren.

=== Skript erstellen ===
Als Erstes müssen Sie die Datei <code>/usr/local/sbin/debian-backup.sh</code> erstellen:
<pre>nano /usr/local/sbin/debian-backup.sh</pre>
Erstellen Sie folgendes Skript (wählen Sie die in <code><></code> enthaltenen Werte entsprechend Ihrer Einstellungen):
<pre>#!/bin/bash
set -euo pipefail

export PBS_REPOSITORY="<user>@<pam>@<IPadresse>:<Datastore>"
export PBS_PASSWORD="<Password>"

proxmox-backup-client backup \
home.pxar:/<Verzeichnis></pre>
Machen Sie das Skript danach ausführbar:
<pre>chmod +x debian-backup.sh</pre>

=== Cron installieren und konfigurieren ===
Als Nächstes muss '''Cron''' mit folgenden Befehlen installiert werden:
<pre>sudo apt update

sudo apt install cron
</pre>
Dann die '''Cron'''-Datei erstellen:
<pre>
sudo crontab -e
</pre>
Wollen Sie Ihre Daten täglich um 03:30 Uhr in der Nacht sichern, fügen Sie der Datei folgenden Text hinzu:
<pre>
30 3 * * * /usr/local/sbin/debian-backup.sh
</pre>
Für eine ausführliche Anleitung, wie man Cron-Jobs anlegt bzw. ändert konsultieren Sie folgenden Artikel: https://wiki.ubuntuusers.de/Cron/ .

Autor: Paul Streifinger

Paul Streifinger arbeitet als Auszubildender im Product Management Team von Thomas-Krenn. Er absolvierte an der Realschule Freyung seine Mittlere Reife und macht seine Ausbildung als Fachinformatiker für Systemintegration bei der Thomas-Krenn.AG. Während seiner Ausbildung beschäftigt er sich mit Proxmox VE (inkl. Ceph und Backup) und mit VMware.

Advantech Industrie Firewall Server

2026-03-24T11:26:45Z

Aranzinger:

Für den Betrieb einer Open Source Firewall wie OPNsense eignet sich eine große Anzahl verschiedener Serversysteme. In diesem Artikel stellen wir einige Advantech Industrie Firewall Systeme vor, die wir bei Thomas-Krenn speziell mit OPNsense getestet haben.

Hier geht es zu unseren OPNsense Industrie-Firewalls im Onlineshop von Thomas-Krenn

== Firewall optimierte Advantech Systeme ==
Die folgende Tabelle zeigt Advantech Systeme, die wir bei Thomas-Krenn speziell mit OPNsense getestet haben:

Server	<tklink type="sitex" id="20756">UNO-2271G V2</tklink><br>	<tklink type="sitex" id="20804">FWA-1012VC-4CA1S</tklink><br>	<tklink type="sitex" id="20803">FWA-1012VC-8CA1S</tklink><br>	<tklink type="sitex" id="20805">FWA-1112VC-4CA1S</tklink><br>	<tklink type="sitex" id="20802">FWA-2012-16A1S</tklink><br>	<tklink type="sitex" id="21233">FWA-1214LRI-4CA1R</tklink><br>	<tklink type="sitex" id="21233">FWA-1214FRI-8CA1R</tklink><br>	<tklink type="sitex" id="21123">FWA-3034</tklink><br>	<tklink type="sitex" id="21073">FWA-5072-00A1R</tklink><br>
Besonderheiten	Lüfterlos 2 NICs optional 2 zusätzliche NICs (2x i350)	4 NICs 2 SFP Intel QAT	6 NICs 2 SFP Intel QAT	6 NICs 2 SFP+ 10 Gbit Intel QAT Hoher Temperaturbereich	6 NICs Intel QAT 1x NMC	4 Kerne (Atom x7433RE) 4 NICs	8 Kerne (Atom x7835RE) 4 NICs 2 SFP (FWA-1214FRI-8CA1R)	Front I/O 8x 2,5 Gbit onboard 2x 10 Gbit onboard 1x NMC red. NT	Front I/O 4x NMC red. NT
Mainboard	UNO-2271G-N221AE	FWA-1012VC 4-Core	FWA-1012VC 8-Core	Advantech Mainboard FWA-1112VC	Advantech Mainboard FWA-2012	Advantech Mainboard FWA-1214	Advantech Mainboard FWA-1214	Advantech Mainboard FWA-3034	Advantech Mainboard FWA-5072-00A1R
CPU<br><br> Taktfrequenz Cores / Threads AES-NI Instructions	Celeron N6210<br><br> 1,2 GHz 2 / 2 Ja	Atom C3558<br><br> 2,2 GHz 4 / 4 Ja	Atom C3758<br><br> 2,2 GHz 8 / 8 Ja	Atom C3558<br><br> 2,2 GHz 4 / 4 Ja	Atom C3958<br><br> 2,0 GHz 16 /16 Ja	Atom x7433RE<br><br> 3,4 GHz 4 / 4 Ja	Atom x7835RE<br><br> 3,6 GHz 8 / 8 Ja	Core i3-13100TE - Core i7-12700E<br><br> 4,1 - 5,1 GHz 8 / 8 - 12 / 20 Ja	Xeon Silver 4509Y - Xeon Platinum 8580<br><br> 2,0 - 3,9 GHz 8 / 16 - 60 / 120 Ja
RAM	2 - 8 GB	8 - 32 GB	8 - 32 GB	8 - 32 GB	8 - 32 GB	8 GB	8 GB	8 - 64 GB	16 - 1024 GB
Disk (SATA)	-	-	-	-	-	-	-	2	2
Disk (NVMe und weitere)	32 GB eMMC onboard 1 mSATA	1 SATA M.2 2280	1 SATA M.2 2242/2280	1 SATA M.2 2280	1 SATA M.2 2280	64GB M.2 SATA SSD 2242 onboard	64GB M.2 SATA SSD 2242 onboard	1 SATA/NVMe M.2 2280	2 SATA/NVMe M.2 2280
NICs 1 Gbit (enthalten)	2 (2x i211)	6 (4x RJ45, 2x SFP)	8 (6x RJ45, 2x SFP)	4 (2x i211, 2x X553 L)	6 (6x RJ45)	4 (4x RJ45)	6 (4x RJ45 und 2x SFP)	2 (2x SFP)	2 (2x RJ45)
NICs 2,5 Gbit (enthalten)	-	-	-	-	-	-	-	8 (8x i226-LM)	-
NICs 10 Gbit (enthalten)	-	-	-	2 (2x X553 N)	-	-	-	2 (2x X710)	-
NICs 25 Gbit (enthalten)	-	-	-	-	-	-	-	-	-

Autor: Thomas Niedermeier

KeePassXC Passwortmanager

2026-03-13T10:45:39Z

Aranzinger:

'''KeePassXC''' ist ein Open Source Passwordmanager für Windows, Linux, BSD und Mac OS. Zum Speichern der Passwörter verwendet KeePassXC das KeePass 2.x (.kdbx) Datenbankformat. Damit kann eine solche Datanbankdatei auch mit anderen Systemen genutzt werden, zum Beispiel mit KeePassDX (Open Source Password Manager für Android) wenn die Datei dorthin kopiert wird.

== Sicherheit ==
KeePassXC führt '''keine Synchronisierung''' zu Cloudanbietern durch, '''sämtliche Passwörter bleiben am eigenen Rechner''' (außer man kopiert oder synchronisiert selbst die .kdbx Datenbankdatei z.B. auf sein Smartphone).

Cloud-spezifische Sicherheitslücken von cloudbasierten Passwortmanagern, wie sie beispielsweise die ETH Zürich im Februar 2026 für drei Cloudlösungen veröffentlicht hat,<ref>Passwortmanager bieten weniger Schutz als versprochen (ethz.ch, 16.02.2026)</ref> können damit architekturbedingt nicht auftreten.

Darüber hinaus stellt das BSI Informationen zur Sicherheit von Passwortmanagern weiterführende Informationen bereit.<ref>Passwörter verwalten mit einem Passwort-Manager (www.bsi.bund.de)</ref>

== Installation ==
KeePassXC steht zum Download auf der KeePassXC Webseite zur Verfügung.<ref>Download KeePassXC (keepassxc.org)</ref> Unter Linux ist die Installation via Flatpak Paket empfohlen.

Unter Linux Mint kann KeePassXC damit bequem über den Software-Manager installiert werden (Quelle Flatpak (Flathub) auswählen):

== Einrichtung ==
Die folgenden Screenshots zeigen die Einrichtung von KeePassXC:
<gallery>
File:KeePassXC-01-Welcome-to-KeePassXC.png|Auf "Create Database" klicken.
File:KeePassXC-02-Create-new-database.png|Datenbankname und optional eine Beschreibung eingeben.
File:KeePassXC-03-Encryption-settings.png|Als Datenbankformat die Standardeinstellung KDBX 4 belassen.
File:KeePassXC-04-Encryption-settings-advanced.png|Unter "Advanced" können Details zur Verschlüsselung verändert werden.
File:KeePassXC-05-Database-credentials.png|Master-Passwort festlegen.
File:KeePassXC-05-Database-credentials-additional-protection.png|Nach Klick auf "Add additional protection..." können noch ein Key File und ein Challenge-Response Verfahren optional konfiguriert werden.
File:KeePassXC-07-Save-database-as.png|Dateiname und Ordner für die Datenbankdatei festlegen.
File:KeePassXC-08.png|Datenbank wurde angelegt.
File:KeePassXC-09-Add-new-entry.png|Durch Klicken auf "+" kann ein neuer Passwort-Eintrag erstellt werden.
File:KeePassXC-10-Entry.png|Entry
File:KeePassXC-11-Advanced.png|Advanced
File:KeePassXC-12-Icon.png|Icon
File:KeePassXC-13-Auto-Type.png|Auto-Type
File:KeePassXC-14-Properties.png|Properties
File:KeePassXC-15-Entry-OK.png|Nach der Einstellung aller Parameter auf "OK" klicken.
File:KeePassXC-16.png|Der Eintrag (für Mastodon in diesem Beispiel) ist nun erstellt.
File:KeePassXC-17-right-click.png|Ein Rechtsklick auf den Eintrag zeigt mögliche Aktionen.
File:KeePassXC-18-unlock.png|Wenn KeePassXC geschlossen und neu gestartet wird, muss das Master-Passwort eingegeben werden.
File:KeePassXC-19.png|Nach Eingabe des Master-Passworts sind die erstellten Einträge wieder ersichtlich.
</gallery>

== Weitere Informationen ==

KeePassXC Password Manager (keepassxc.org)
Passkeys With KeePassXC - An Introduction (www.freiburg.linux.de, 17.09.2025) Vortrag von Janek Bevendorff (KeePassXC Maintainer) bei der Freiburger Linux User Group.

== Einzelnachweise ==
<references />

Autor: Werner Fischer

Werner Fischer arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.

Ergänzung zu Sicherheitshinweise Intel Produkten 2026.1 IPU

2026-03-13T07:15:39Z

Aranzinger:

Im März '''2026''' wurden von Intel im Rahmen des IPU 2026.1 nochmals neue Security Advisories (Sicherheitshinweise) zu verschiedenen Intel-Produkten veröffentlicht. Manche dieser Sicherheitshinweise erfordern '''Firmware Updates'''.

In diesem Artikel finden Sie einen Auszug und Hinweise zu diesen Security Advisories sowie Informationen, wo Sie Updates für Produkte von Thomas-Krenn finden werden.

== Security Advisories ==
Hier in der Tabelle finden Sie die Sicherheitshinweise zur Firmware die von Intel veröffentlicht wurden.

Intel Security Advisory	Titel	Betroffene Systeme
INTEL-SA-01393	2026.1 IPU, UEFI Reference Firmware Advisory	(siehe Intel-SA)
INTEL-SA-01234	2025.3 IPU, UEFI Reference Firmware Advisory

== Updates für Produkte von Thomas-Krenn ==
Updates zum jeweiligen System finden Sie im <tklink type="sitex" id="440">Downloadbereich von Thomas-Krenn</tklink>.
Die Updates im Downloadbereich wurden von uns getestet, um die Stabilität und Kompatibilität unserer Systeme zu gewährleisten.

Falls Sie die aktuellste Version für ihr System benötigen und diese noch nicht bei uns im Downloadbereich zu finden ist, können Sie diese im Downloadbereich bei Asus , Supermicro oder Gigabyte beziehen.

== Weitere Informationen ==

Security Center (www.intel.com)

Autor: Thomas-Krenn.AG

Qemu drive cache Option

2026-03-02T15:10:10Z

Aranzinger:

'''Quick Emulator''' ('''QEMU''') ist ein Open Source Emulator, der unter anderem virtuelle Hardware emuliert. QEMU kann gemeinsam mit KVM genutzt werden und kommt auf diese Art bei Proxmox VE zum Einsatz. In diesem Artikel geht es grundsätzlich um die QEMU drive Option "cache". Die Konfiguration eines QEMU drive enthält die Erzeugung eines block driver nodes (backend) sowie eines Gastgeräts.

== cache Option ==
Die Option "cache" steuert wie der Host-Cache für den Zugriff auf Blockdaten verwendet wird.

Die Option "cache" ist eine Verknüpfung, welche die drei Optionen '''cache.direct''', '''cache.no-flush''' (beide wie in -blockdev) sowie zusätzlich '''cache.writeback''' (-device) festlegt. Die fünf cache-Modi writeback, none, writethrough, directsync und unsafe entsprechen den folgenden Einstellungen:<ref>QEMU User Documentation (Manpage) - Block device options (www.qemu.org/docs) <cite>cache is “none”, “writeback”, “unsafe”, “directsync” or “writethrough” and controls how the host cache is used to access block data. This is a shortcut that sets the cache.direct and cache.no-flush options (as in -blockdev), and additionally cache.writeback, which provides a default for the write-cache option of block guest devices (as in -device).</cite></ref>


cache	-device Option	-blockdev Optionen	Anmerkungen<ref>libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable (opendev.org/openstack/nova, 04.05.2019) <cite>The thing that makes 'writethrough' so safe against host crashes is that it never keeps data in a "write cache", but it calls fsync() after _every_ write. This is also what makes it horribly slow. But 'cache=none' doesn't do this and therefore doesn't provide this kind of safety. The guest OS must explicitly flush the cache in the right places to make sure data is safe on the disk. And OSes do that.<br> So if 'cache=none' is safe enough for you, then 'cache=writeback' should be safe enough for you, too -- because both of them have the boolean 'cache.writeback=on'. The difference is only in 'cache.direct', but 'cache.direct=on' only bypasses the host kernel page cache and data could still sit in other caches that could be present between QEMU and the disk (such as commonly a volatile write cache on the disk itself).</cite></ref>
Name QEMU	Name Proxmox VE GUI	cache.writeback	cache.direct	cache.no-flush	Gewährleistung Datenintegrität nach einem plötzlichen Ausfall des Hosts	Schreib-Performance
writeback	Write back	✔ (on)	-	-	Hoch, wenn das Gast-Betriebssystem/Dateisystem regelmäßig den Cache-Inhalt auf Disk schreibt (flush). Dies wird von modernen Dateisystemen in der Regel automatisch durchgeführt. Siehe dazu auch Ext4 Write Barriers.	Pagecache des Hosts wird verwendet.	Hoch
none	No cache	✔ (on)	✔ (on)	-	Pagecache des Hosts wird nicht verwendet. Dennoch können sich Daten in anderen Caches (z.B. Cache einer HDD) befinden. Daher muss das Gast-Betriebssystem dennoch regelmäßig flushes durchführen.
writethrough	Write through	-	-	-	Sehr hoch, da QEMU mit Cache Modus "writethrough" Daten niemals in einem "Schreibcache" speichert, sondern '''nach jedem Schreibvorgang die Funktion fsync() aufruft'''.	Pagecache des Hosts wird verwendet.	Geringer, da nach jedem Schreibvorgang die Funktion fsync() aufgerufen wird.
directsync	Direct sync	-	✔ (on)	-	Pagecache des Hosts wird nicht verwendet.
unsafe	Write back (unsafe)	✔ (on)	-	✔ (on)	Keine Gewährleistung der Datenintegrität! Hohes Risiko eines Datenverlustes! Dieser Caching-Modus soll nur für temporäre Daten verwendet werden, bei denen Datenverlust kein Problem darstellt. Dieser Modus kann zur Beschleunigung von Gastinstallationen nützlich sein, danach sollte aber in Produktionsumgebungen unbedingt zu einem anderen Caching-Modus gewechselt werden.<ref>https://opendev.org/openstack/nova/src/commit/18a7dcb6e816e26e405259e981498f6a7bc71608/nova/conf/libvirt.py#L724</ref>	Pagecache des Hosts wird verwendet.	Am höchsten

Der Standardmodus in Qemu ist cache=writeback. Bei Proxmox VE wird none (No cache) als Standard verwendet.

=== cache.writeback ===
Standardmäßig wird der Modus '''cache.writeback=on''' verwendet. Dabei werden Datenschreibvorgänge als abgeschlossen gemeldet, sobald die Daten im Host-Pagecache vorhanden sind. Dies ist sicher, solange Ihr Gastbetriebssystem dafür sorgt, dass die Festplatten-Caches bei Bedarf korrekt geleert werden. Wenn Ihr Gastbetriebssystem volatile Festplatten-Schreib-Caches nicht korrekt verarbeitet und Ihr Host abstürzt oder die Stromversorgung ausfällt, kann es zu Datenbeschädigungen im Gastbetriebssystem kommen.

Für solche Gäste sollten Sie die Verwendung von cache.writeback=off in Betracht ziehen. Das bedeutet, dass der Host-Pagecache zum Lesen und Schreiben von Daten verwendet wird, aber die Schreibbenachrichtigung erst dann an den Gast gesendet wird, nachdem QEMU sichergestellt hat, dass jeder Schreibvorgang auf die Festplatte geleert wurde. Beachten Sie, dass dies erhebliche Auswirkungen auf die Leistung hat.<ref>QEMU User Documentation (Manpage) - Block device options (www.qemu.org/docs) <cite>By default, the cache.writeback=on mode is used. It will report data writes as completed as soon as the data is present in the host page cache. This is safe as long as your guest OS makes sure to correctly flush disk caches where needed. If your guest OS does not handle volatile disk write caches correctly and your host crashes or loses power, then the guest may experience data corruption. 
For such guests, you should consider using cache.writeback=off. This means that the host page cache will be used to read and write data, but write notification will be sent to the guest only after QEMU has made sure to flush each write to the disk. Be aware that this has a major impact on performance.</cite></ref>


Disk (Einstellung Proxmox VE GUI)	Abfrage Cache via	Ergebnis bei cache.writeback=on	Ergebnis bei cache.writeback=off	Anmerkung
IDE	<nowiki>hdparm -I /dev/sdc \| grep "Write cache"</nowiki>	* Write cache	Write cache (kein Stern davor)	hdparm führt ein ATA IDENTIFY DEVICE Kommando aus, um die Einstellung abzufragen.
SATA
VirtIO Block	cat /sys/block/vda/queue/write_cache	write back	write through	Der VirtIO Block Treiber stellt die Information via sysfs zur Verfügung.
SCSI	sdparm --get=WCE /dev/sda	WCE = 1	WCE = 0	sdparm führt ein SCSI MODE SENSE Kommando aus, um die Einstellung abzufragen. WCE steht dabei für "Writeback Cache Enable".

=== chache.direct ===
'''cache.direct=on''' umgeht den Host Pagecache. Dadurch wird versucht, die Disk-I/O direkt im Memory des Gasts auszuführen. QEMU führt möglicherweise weiterhin eine interne Kopie der Daten durch.

=== cache.no-flush ===
'''cache.no-flush''' ('''Achtung - Gefahr von Datenverlust! - nur verwenden, wenn Datenintegrität nicht wichtig ist, etwa bei reinen Tests''') teilt QEMU mit, dass es niemals Daten auf die Festplatte schreiben muss, sondern stattdessen alles im Cache speichern kann. Wenn etwas schief geht, z. B. wenn Ihr Host keinen Strom mehr hat, die Festplatte versehentlich getrennt wird usw., wird Ihr Image höchstwahrscheinlich unbrauchbar.

== Tests ==
Die folgenden Tests sind auf einem lvmthin Volume durchgeführt worden. Diese unterstützen ausschließlich raw (kein qcow2).<ref>https://forum.proxmox.com/threads/proxmox-disks-changed-from-qcow-to-raw-after-migration.96007/#post-417101</ref> Für Hintergründe zu cache=none bei qcow2 verweisen wir auf den Beitrag "Understanding QCOW2 Risks with QEMU cache=none in Proxmox".<ref>Understanding QCOW2 Risks with QEMU cache=none in Proxmox (kb.blockbridge.com)</ref>

Mit dem diskchecker.pl Perl Skript haben wir getestet, ob Daten bei einem Stromausfall verloren gehen können. Hintergrundinformationen zu diesem Skript gibt es hier: http://brad.livejournal.com/2116715.html

Debian 13 VM mit raw
Cache Einstellung	diskchecker.pl Ergebnis
Default (No cache)	Total errors: 0
Write back (unsafe)	Total errors: 2786
Write through	Total errors: 0
Write back	Total errors: 0
Direct sync	Total errors: 0

=== Default (No cache) ===
<pre>
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file 1000

 diskchecker: running 1 sec, 0.46% coverage of 1000 MB (293 writes; 293/s)

 diskchecker: running 2 sec, 1.06% coverage of 1000 MB (684 writes; 342/s)

 diskchecker: running 3 sec, 1.70% coverage of 1000 MB (1099 writes; 366/s)

 diskchecker: running 4 sec, 2.33% coverage of 1000 MB (1507 writes; 376/s)

 diskchecker: running 5 sec, 2.93% coverage of 1000 MB (1907 writes; 381/s)

 diskchecker: running 6 sec, 3.58% coverage of 1000 MB (2326 writes; 387/s)

 diskchecker: running 7 sec, 4.20% coverage of 1000 MB (2739 writes; 391/s)

 diskchecker: running 8 sec, 4.81% coverage of 1000 MB (3152 writes; 394/s)

 diskchecker: running 9 sec, 5.40% coverage of 1000 MB (3553 writes; 394/s)

 diskchecker: running 10 sec, 6.03% coverage of 1000 MB (3976 writes; 397/s)

[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file

verifying: 0.03%

verifying: 46.22%

verifying: 100.00%

Total errors: 0
tk@debian13-1:~$
</pre>

=== Write back (unsafe) ===
<pre>
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_unsafe 1000

 diskchecker: running 1 sec, 0.45% coverage of 1000 MB (286 writes; 286/s)

 diskchecker: running 2 sec, 1.22% coverage of 1000 MB (782 writes; 391/s)

 diskchecker: running 3 sec, 2.06% coverage of 1000 MB (1328 writes; 442/s)

 diskchecker: running 4 sec, 2.81% coverage of 1000 MB (1820 writes; 455/s)

 diskchecker: running 5 sec, 3.55% coverage of 1000 MB (2306 writes; 461/s)

 diskchecker: running 6 sec, 4.25% coverage of 1000 MB (2778 writes; 463/s)

 diskchecker: running 7 sec, 5.04% coverage of 1000 MB (3302 writes; 471/s)

 diskchecker: running 8 sec, 5.85% coverage of 1000 MB (3863 writes; 482/s)

 diskchecker: running 9 sec, 6.73% coverage of 1000 MB (4466 writes; 496/s)

 diskchecker: running 10 sec, 7.50% coverage of 1000 MB (4984 writes; 498/s)

[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_unsafe

verifying: 0.02%

 Error at page 26, 4 seconds before end.

 Error at page 34, 6 seconds before end.

 Error at page 49, 3 seconds before end.

 Error at page 123, 0 seconds before end.

 Error at page 166, 0 seconds before end.

 Error at page 167, 6 seconds before end.

 Error at page 169, 1 seconds before end.

 Error at page 199, 1 seconds before end.

 Error at page 200, 2 seconds before end.

 Error at page 214, 4 seconds before end.

[...]

verifying: 100.00%

Total errors: 2786
Histogram of seconds before end:

tk@debian13-1:~$
</pre>

=== Write through ===
<pre>
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_writethrough 1000

 diskchecker: running 1 sec, 0.36% coverage of 1000 MB (234 writes; 234/s)

 diskchecker: running 2 sec, 0.92% coverage of 1000 MB (587 writes; 293/s)

 diskchecker: running 3 sec, 1.45% coverage of 1000 MB (929 writes; 309/s)

 diskchecker: running 4 sec, 1.97% coverage of 1000 MB (1268 writes; 317/s)

 diskchecker: running 5 sec, 2.49% coverage of 1000 MB (1612 writes; 322/s)

 diskchecker: running 6 sec, 3.02% coverage of 1000 MB (1957 writes; 326/s)

 diskchecker: running 7 sec, 3.53% coverage of 1000 MB (2295 writes; 327/s)

 diskchecker: running 8 sec, 4.07% coverage of 1000 MB (2650 writes; 331/s)

 diskchecker: running 9 sec, 4.57% coverage of 1000 MB (2989 writes; 332/s)

 diskchecker: running 10 sec, 5.07% coverage of 1000 MB (3327 writes; 332/s)

[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_writethrough

verifying: 0.02%

verifying: 56.67%

verifying: 100.00%

Total errors: 0
tk@debian13-1:~$
</pre>

=== Write back ===
<pre>
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_writeback 1000

 diskchecker: running 1 sec, 0.45% coverage of 1000 MB (289 writes; 289/s)

 diskchecker: running 2 sec, 1.03% coverage of 1000 MB (671 writes; 335/s)

 diskchecker: running 3 sec, 1.62% coverage of 1000 MB (1051 writes; 350/s)

 diskchecker: running 4 sec, 2.21% coverage of 1000 MB (1438 writes; 359/s)

 diskchecker: running 5 sec, 2.82% coverage of 1000 MB (1831 writes; 366/s)

 diskchecker: running 6 sec, 3.40% coverage of 1000 MB (2224 writes; 370/s)

 diskchecker: running 7 sec, 3.98% coverage of 1000 MB (2611 writes; 373/s)

 diskchecker: running 8 sec, 4.56% coverage of 1000 MB (3005 writes; 375/s)

 diskchecker: running 9 sec, 5.15% coverage of 1000 MB (3397 writes; 377/s)

 diskchecker: running 10 sec, 5.73% coverage of 1000 MB (3788 writes; 378/s)

[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_writeback

verifying: 0.03%

verifying: 47.70%

verifying: 100.00%

Total errors: 0
tk@debian13-1:~$
</pre>

=== Direct sync ===
<pre>
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_directsync 1000

 diskchecker: running 1 sec, 0.38% coverage of 1000 MB (246 writes; 246/s)

 diskchecker: running 2 sec, 0.90% coverage of 1000 MB (579 writes; 289/s)

 diskchecker: running 3 sec, 1.49% coverage of 1000 MB (960 writes; 320/s)

 diskchecker: running 4 sec, 2.01% coverage of 1000 MB (1302 writes; 325/s)

 diskchecker: running 5 sec, 2.53% coverage of 1000 MB (1643 writes; 328/s)

 diskchecker: running 6 sec, 3.08% coverage of 1000 MB (2006 writes; 334/s)

 diskchecker: running 7 sec, 3.61% coverage of 1000 MB (2363 writes; 337/s)

 diskchecker: running 8 sec, 4.16% coverage of 1000 MB (2721 writes; 340/s)

 diskchecker: running 9 sec, 4.74% coverage of 1000 MB (3108 writes; 345/s)

 diskchecker: running 10 sec, 5.26% coverage of 1000 MB (3463 writes; 346/s)

[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_directsync

verifying: 0.01%

verifying: 57.56%

verifying: 100.00%

Total errors: 0
tk@debian13-1:~$
</pre>

== Weitere Informationen ==

Storage Performance Tuning for FAST! Virtual Machines
Disk Cache Modes (documentation.suse.com)

== Einzelnachweise ==
<references />

Autor: Werner Fischer

TKMI Logs & Reports

2026-02-27T15:08:18Z

Aranzinger:

Das TKMI erfasst verschiedene '''Systemberichte'''. Jeder Bericht ist auf einen bestimmten Nutzen ausgerichtet. Im folgenden werden die Berichte im Einzelnen vorgestellt.

== IPMI Event Log ==

TKMI IPMI & Event Log

Dieser Bericht listet alle im ''Intelligent Platform Management Interface (IPMI)'' erfassten Ereignisse chronologisch auf.

Mithilfe von Filter-Einstellungen können spezifische Einträge gesucht werden:

'''Filter by Date''': Die angezeigten Ereignisse werden auf einen festgelegten Zeitraum begrenzt.
'''Filter by type''': Die angezeigten Ereignisse werden auf spezifische Ereignisse oder Sensoren festgelegt.

Mithilfe des Buttons ''Clear Event Logs'' können die bisher erfassten Ereignisse gelöscht werden.

Mithilfe des Buttons ''Download Event Logs'' können die erfassten Ereignisse exportiert werden.

Außerdem erhält man eine Statistik über die Anzahl der monatlich erfassten Ereignisse als Balkendiagramm.
== Operation Log ==

TKMI Operation Log

Dieser Bericht listet alle Ereignisse das Host-System betreffend chronologisch auf.

Folgende Optionen stehen bei der Darstellung zur Verfügung:

'''Filter by Date''': Start- und Endzeitpunkt der gelisteten Operationen können festgelegt werden. Ermöglicht die Begrenzung auf bestimmte Zeiträume.
'''Event Category''': Es können entweder ''Information'' oder ''Warning'' Logs angezeigt werden. Erstere enthalten einfache Status-Ereignisse, letztere listen nur Ereignisse, die mit Warnungen verbunden sind.

Mithilfe des Buttons ''Clear Logs'' werden alle vorhandenen Log-Einträge gelöscht.

Mithilfe des Buttons ''Download Logs'' können alle vorhanden Log-Einträge heruntergeladen werden. Die Einträge werden im <code>log</code> Dateiformat, verpackt in einem <code>tgz</code>-Archiv gespeichert.

== Audit Log ==

TKMI Audit Log

Dieser Bericht listet alle Ereignisse über das Host-System auf, welche zur Sicherstellung von Compliance, Sicherheit und Problemlösung dienen.

Insbesondere finden sich in den Systemberichten die Nutzerkennung und die IP-Adresse der durchgeführten Aktionen wieder.

Folgende Optionen stehen bei der Darstellung zur Verfügung:

'''Filter by Date''': Start- und Endzeitpunkt der gelisteten Operationen können festgelegt werden. Ermöglicht die Begrenzung auf bestimmte Zeiträume.

TKMI Video Log

Dieser Bericht listet über das Host System aufgenommene Videos auf. Einstellungen zu Video-Trigger, Aufnahmequalität und Speicherort können in den TKMI Settings eingestellt werden.

Folgende Optionen stehen bei der Darstellung zur Verfügung:

'''Filter by Date''': Start- und Endzeitpunkt der gelisteten Operationen können festgelegt werden. Ermöglicht die Begrenzung auf bestimmte Zeiträume.

Mithilfe des Buttons ''Clear Logs'' werden alle vorhandenen Log-Einträge gelöscht.

== SOL Video Log ==

TKMI Serial on LAN (SOL) Log

Dieser Bericht listet über eine ''Serial over LAN'' aufgenommene Video-Dateien auf. Einstellungen zu Video-Trigger, Aufnahmequalität und Speicherort können in den TKMI Settings eingestellt werden.

Folgende Optionen stehen bei der Darstellung zur Verfügung:

'''Filter by Date''': Start- und Endzeitpunkt der gelisteten Operationen können festgelegt werden. Ermöglicht die Begrenzung auf bestimmte Zeiträume.

Mithilfe des Buttons ''Clear Logs'' werden alle vorhandenen Log-Einträge gelöscht.

Autor: Stefan Bohn

Stefan Bohn ist seit 2020 bei der Thomas-Krenn.AG beschäftigt. Ursprünglich als Berater für IT-Lösungen im PreSales beheimatet, wechselte er 2022 zum Product Management. Dort widmet er sich dem Wissenstransfer und treibt dabei auch das Thomas-Krenn Wiki voran.

Ext4 Write Barriers

2026-02-27T13:26:05Z

Aranzinger:

'''Write Barriers''' (Schreibbarrieren) dienen im Linux Kernel dazu, bisher geschriebene Daten tatsächlich auf auf einen Datenträger '''permanent''' geschrieben zu haben, bevor weitere neue Daten geschrieben werden. Der Einsatz von Write Barriers stellt sicher, dass selbst im Falle eines plötzlichen Stromausfalles '''keine via fsync() geschriebenen Daten verloren gehen'''. Schreibbarrieren erzwingen die '''korrekte Reihenfolge von Journal-Commits''' des Dateisystems auf dem Datenträger, wodurch flüchtige Schreib-Caches sicher verwendet werden können (allerdings mit gewissen Leistungseinbußen).

== Funktionsweise von Write Barriers ==
Schreibbarrieren werden im Linux-Kernel über das Leeren (flush) des Speicher-Schreibcaches '''vor''' und '''nach''' der I/O Operation implementiert. Nach dem '''Schreiben einer Transaktion''' wird der '''Speicher-Cache geleert''' (flush), der '''Commit-Block des Dateisystems geschrieben''' und der '''Cache erneut geleert'''. Dadurch wird sichergestellt, dass:

Der Datenträger (Festplatte oder SSD) alle Daten enthält.
Keine Neuanordnung (re-ordering) der einzelnen Zugriffe stattgefunden hat.

Wenn Barrieren aktiviert sind, löst ein fsync()-Aufruf ebenfalls einen Speicher-Cache-Flush aus. Dies garantiert, dass die Dateidaten auf der Festplatte dauerhaft gespeichert bleiben, selbst wenn kurz nach der Rückgabe von fsync() ein Stromausfall auftritt.

== Ext4 Dateisystem als Beispiel ==
Das Ext4 Dateisystem verwendet seit Mai 2008 standardmäßig Write Barriers.<ref>ext4: enable barriers by default (git.kernel.org, 26.05.2008)</ref> Dadurch wird sichergestellt, dass auch bei Datenträgern mit flüchtigen Caches - z.B. bei Festplatten mit RAM-Caches - selbst bei einem plötzlichen Stromausfall keine Daten verloren gehen, dis mittels fsync() geschrieben wurden.

Die Aktivierung von Schreibbarrieren kann bei einigen Anwendungen zu erheblichen Leistungseinbußen führen. Insbesondere Anwendungen, die fsync() intensiv nutzen oder viele kleine Dateien erstellen und löschen, laufen mitunter deutlich langsamer.<ref>Chapter 22. Write Barriers (docs.redhat.com, Storage Administration Guide RHEL 7) <cite>Enabling write barriers incurs a substantial performance penalty for some applications. Specifically, applications that use fsync() heavily or create and delete many small files will likely run much slower.</cite></ref> Wenn RAID-Controller mit battery-backed Cache oder bespielsweise SSDs mit SSD Power Loss Protection verwendet werden, kann das Deaktivieren von write barriers die Performance steigern, ohne das Risiko eines Datenverlustes zu erhöhen.<ref>PostgreSQL File System Tuning - Write Barrier Tuning (kb.techtaco.org)</ref> Das gilt jedoch nur dann, wenn tatsächlich eine funktionierende Power-Loss-Protection vorhanden ist.


Testfall	HDD Western Digigital WD5003ABYX	Intel SSD mit PLP	Samsung SSD ohne PLP
barriers=1 (aktiviert)	kein Datenverlust	kein Datenverlust	kein Datenverlust
barriers=0 (deaktiviert)	Datenverlust	kein Datenverlust	kein Datenverlust (Achtung: Datenverlust dennoch nicht ausgeschlossen!)

== Ext4 Dateisystemtests mit diskchecker.pl ==
Die folgendes Tests wurden alle mit dem diskchecker.pl Perl Skript durchgeführt. Mit dem Testscript wird mithilfe von zwei Rechnern geprüft, ob Daten bei einem Stromausfall verloren gehen können. Dazu wird das Skript auf zwei Rechnern ausgeführt:

auf einem Protokollierungs-Rechner: dort läuft das Skript im Servermodus.
auf dem zu testenden System: dort wird nachdem das Skript gestartet wurde, die Stromzuvor unterbrochen.

Danach wird das zu testende System erneut angesteckt und gestartet. Das Skript wird nun erneut zur Verifizierung ausgeführt. Weitere Hintergrundinformationen zu diesem Skript gibt es hier: http://brad.livejournal.com/2116715.html

=== Test mit WD 500 GByte HDD ===

Western Digital WD5003ABYX 500GB SATA HDD mit 64MB Cache

In diesem Test wird eine Western Digital WD5003ABYX 500GB SATA HDD mit 64MB Cache verwendet.

==== barrier=1 (default) ====
<pre>
root@pve:~# mount | grep sdc
/dev/sdc1 on /mnt/sdc-hdd type ext4 (rw,relatime)
root@pve:~# uname -a
Linux pve 6.17.2-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64 GNU/Linux
root@pve:/mnt/sdc-hdd# ./diskchecker.pl -s 172.16.0.112 create test-hdd-ext4-default 1000

 diskchecker: running 1 sec, 0.02% coverage of 1000 MB (11 writes; 11/s)

 diskchecker: running 2 sec, 0.05% coverage of 1000 MB (35 writes; 17/s)

 diskchecker: running 3 sec, 0.09% coverage of 1000 MB (59 writes; 19/s)

 diskchecker: running 4 sec, 0.13% coverage of 1000 MB (83 writes; 20/s)

 diskchecker: running 5 sec, 0.17% coverage of 1000 MB (107 writes; 21/s)

 diskchecker: running 6 sec, 0.20% coverage of 1000 MB (132 writes; 22/s)

 diskchecker: running 7 sec, 0.24% coverage of 1000 MB (155 writes; 22/s)

 diskchecker: running 8 sec, 0.28% coverage of 1000 MB (180 writes; 22/s)

 diskchecker: running 9 sec, 0.32% coverage of 1000 MB (204 writes; 22/s)

 diskchecker: running 10 sec, 0.36% coverage of 1000 MB (229 writes; 22/s)

 diskchecker: running 11 sec, 0.39% coverage of 1000 MB (252 writes; 22/s)

 diskchecker: running 12 sec, 0.43% coverage of 1000 MB (276 writes; 23/s)

 diskchecker: running 13 sec, 0.47% coverage of 1000 MB (300 writes; 23/s)

 diskchecker: running 14 sec, 0.50% coverage of 1000 MB (323 writes; 23/s)

 diskchecker: running 15 sec, 0.54% coverage of 1000 MB (347 writes; 23/s)

 diskchecker: running 16 sec, 0.58% coverage of 1000 MB (371 writes; 23/s)

 diskchecker: running 17 sec, 0.62% coverage of 1000 MB (396 writes; 23/s)

 diskchecker: running 18 sec, 0.66% coverage of 1000 MB (421 writes; 23/s)

 diskchecker: running 19 sec, 0.69% coverage of 1000 MB (445 writes; 23/s)

client_loop: send disconnect: Broken pipe
werner@x390:~/bin$
werner@x390:~/bin$ ssh root@172.16.10.1
root@172.16.10.1's password:
Linux pve 6.17.2-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64
[...]
root@pve:~# mount /dev/sdc1 /mnt/sdc-hdd
root@pve:~# dmesg | tail -4
[ 38.545085] vmbr0: port 1(nic1) entered blocking state
[ 38.545091] vmbr0: port 1(nic1) entered forwarding state
[ 207.082732] EXT4-fs (sdc1): recovery complete
[ 207.101678] EXT4-fs (sdc1): mounted filesystem 8ac821f6-c372-415c-addd-855c3161ded9 r/w with ordered data mode. Quota mode: none.
root@pve:~# cd /mnt/sdc-hdd/
root@pve:/mnt/sdc-hdd# ./diskchecker.pl -s 172.16.0.112 verify test-hdd-ext4-default

verifying: 0.36%

verifying: 19.26%

verifying: 59.26%

verifying: 94.18%

verifying: 100.00%

Total errors: 0
root@pve:/mnt/sdc-hdd#
</pre>

==== barrier=0 ====
<pre>
root@pve:~# mount -t ext4 -o barrier=0 /dev/sdc1 /mnt/sdc-hdd
root@pve:~# mount | grep sdc
/dev/sdc1 on /mnt/sdc-hdd type ext4 (rw,relatime,nobarrier)
root@pve:~# cd /mnt/sdc-hdd
root@pve:/mnt/sdc-hdd# ./diskchecker.pl -s 172.16.0.112 create test-hdd-ext4-nobarrier 1000

 diskchecker: running 1 sec, 0.20% coverage of 1000 MB (129 writes; 129/s)

 diskchecker: running 2 sec, 0.62% coverage of 1000 MB (394 writes; 197/s)

 diskchecker: running 3 sec, 0.95% coverage of 1000 MB (608 writes; 202/s)

 diskchecker: running 4 sec, 1.22% coverage of 1000 MB (782 writes; 195/s)

 diskchecker: running 5 sec, 1.55% coverage of 1000 MB (998 writes; 199/s)

 diskchecker: running 6 sec, 1.89% coverage of 1000 MB (1213 writes; 202/s)

 diskchecker: running 7 sec, 2.13% coverage of 1000 MB (1377 writes; 196/s)

 diskchecker: running 8 sec, 2.41% coverage of 1000 MB (1556 writes; 194/s)

 diskchecker: running 9 sec, 2.74% coverage of 1000 MB (1774 writes; 197/s)

 diskchecker: running 10 sec, 3.00% coverage of 1000 MB (1945 writes; 194/s)

 diskchecker: running 11 sec, 3.31% coverage of 1000 MB (2146 writes; 195/s)

 diskchecker: running 12 sec, 3.61% coverage of 1000 MB (2347 writes; 195/s)

 diskchecker: running 13 sec, 3.90% coverage of 1000 MB (2542 writes; 195/s)

 diskchecker: running 14 sec, 4.21% coverage of 1000 MB (2750 writes; 196/s)

 diskchecker: running 15 sec, 4.54% coverage of 1000 MB (2967 writes; 197/s)

 diskchecker: running 16 sec, 4.80% coverage of 1000 MB (3142 writes; 196/s)

 diskchecker: running 17 sec, 5.09% coverage of 1000 MB (3336 writes; 196/s)

 diskchecker: running 18 sec, 5.35% coverage of 1000 MB (3513 writes; 195/s)

 diskchecker: running 19 sec, 5.65% coverage of 1000 MB (3713 writes; 195/s)

 diskchecker: running 20 sec, 5.91% coverage of 1000 MB (3890 writes; 194/s)

 diskchecker: running 21 sec, 6.21% coverage of 1000 MB (4091 writes; 194/s)

 diskchecker: running 22 sec, 6.48% coverage of 1000 MB (4281 writes; 194/s)

 diskchecker: running 23 sec, 6.72% coverage of 1000 MB (4449 writes; 193/s)

 diskchecker: running 24 sec, 7.01% coverage of 1000 MB (4645 writes; 193/s)

</pre>

<pre>
client_loop: send disconnect: Broken pipe
werner@x390:~/bin$ ssh root@172.16.10.1
root@172.16.10.1's password:
Linux pve 6.17.2-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64
[...]
root@pve:~# mount -t ext4 -o barrier=0 /dev/sdc1 /mnt/sdc-hdd
root@pve:~# dmesg | tail -n 4
[ 38.535100] vmbr0: port 1(nic1) entered forwarding state
[ 324.430790] EXT4-fs (sdc1): barriers disabled
[ 327.063895] EXT4-fs (sdc1): recovery complete
[ 327.064076] EXT4-fs (sdc1): mounted filesystem 8ac821f6-c372-415c-addd-855c3161ded9 r/w with ordered data mode. Quota mode: none.
root@pve:~# cd /mnt/sdc-hdd
root@pve:/mnt/sdc-hdd# ./diskchecker.pl -s 172.16.0.112 verify test-hdd-ext4-nobarrier

verifying: 0.02%

 Error at page 19, 2 seconds before end.

 Error at page 303, 1 seconds before end.

 Error at page 339, 0 seconds before end.

 Error at page 511, 1 seconds before end.

 Error at page 544, 0 seconds before end.

 Error at page 681, 0 seconds before end.

 Error at page 708, 2 seconds before end.

 Error at page 1108, 1 seconds before end.

 Error at page 1337, 0 seconds before end.

 Error at page 1388, 0 seconds before end.

verifying: 2.22%

 Error at page 1487, 0 seconds before end.

 Error at page 1492, 0 seconds before end.

[...]

 Error at page 63758, 0 seconds before end.

 Error at page 63990, 1 seconds before end.

verifying: 100.00%

Total errors: 545
Histogram of seconds before end:

root@pve:/mnt/sdc-hdd#
</pre>

=== Test mit SSD mit PLP ===

Intel DC S3500 Series SSD 80 GByte SSD

Innenansicht der SSD. Dabei sind auch die Komponenten für die Power-Loss-Protection (Kondensatoren) zu sehen.

In diesem Beispiel kommt eine 80 GByte Intel DC S3500 Series SSD mit SSD Power Loss Protection zum Einsatz.

==== barrier=1 (default) ====
<pre>
root@pve:/mnt/sdc-ssd-with-plp# mount | grep sdc
/dev/sdc1 on /mnt/sdc-ssd-with-plp type ext4 (rw,relatime)
root@pve:/mnt/sdc-ssd-with-plp# ./diskchecker.pl -s 172.16.0.112 create test-ssd-ext4 1000

 diskchecker: running 1 sec, 0.04% coverage of 1000 MB (28 writes; 28/s)

 diskchecker: running 2 sec, 0.67% coverage of 1000 MB (427 writes; 213/s)

 diskchecker: running 3 sec, 1.34% coverage of 1000 MB (859 writes; 286/s)

 diskchecker: running 4 sec, 2.05% coverage of 1000 MB (1324 writes; 331/s)

 diskchecker: running 5 sec, 2.71% coverage of 1000 MB (1758 writes; 351/s)

 diskchecker: running 6 sec, 3.48% coverage of 1000 MB (2266 writes; 377/s)

 diskchecker: running 7 sec, 4.24% coverage of 1000 MB (2775 writes; 396/s)

 diskchecker: running 8 sec, 4.88% coverage of 1000 MB (3207 writes; 400/s)

 diskchecker: running 9 sec, 5.53% coverage of 1000 MB (3652 writes; 405/s)

 diskchecker: running 10 sec, 6.14% coverage of 1000 MB (4073 writes; 407/s)

 diskchecker: running 11 sec, 6.76% coverage of 1000 MB (4492 writes; 408/s)

 diskchecker: running 12 sec, 7.38% coverage of 1000 MB (4922 writes; 410/s)

 diskchecker: running 13 sec, 7.98% coverage of 1000 MB (5344 writes; 411/s)

 diskchecker: running 14 sec, 8.65% coverage of 1000 MB (5799 writes; 414/s)

 diskchecker: running 15 sec, 9.25% coverage of 1000 MB (6229 writes; 415/s)

 diskchecker: running 16 sec, 9.84% coverage of 1000 MB (6652 writes; 415/s)

 diskchecker: running 17 sec, 10.47% coverage of 1000 MB (7103 writes; 417/s)

 diskchecker: running 18 sec, 11.11% coverage of 1000 MB (7556 writes; 419/s)

 diskchecker: running 19 sec, 11.71% coverage of 1000 MB (7974 writes; 419/s)

 diskchecker: running 20 sec, 12.31% coverage of 1000 MB (8405 writes; 420/s)

 diskchecker: running 21 sec, 12.91% coverage of 1000 MB (8847 writes; 421/s)

 diskchecker: running 22 sec, 13.57% coverage of 1000 MB (9328 writes; 424/s)

 diskchecker: running 23 sec, 14.18% coverage of 1000 MB (9767 writes; 424/s)

</pre>
<pre>
werner@x390:~/bin$ ssh root@172.16.10.1
root@172.16.10.1's password:
Linux pve 6.17.2-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64
[...]
root@pve:~# mount /dev/sdc1 /mnt/sdc-ssd-with-plp
root@pve:~# dmesg | tail -n 4
[ 38.515045] vmbr0: port 1(nic1) entered blocking state
[ 38.515052] vmbr0: port 1(nic1) entered forwarding state
[ 175.603062] EXT4-fs (sdc1): recovery complete
[ 175.603218] EXT4-fs (sdc1): mounted filesystem 2847a7c0-0a1e-4ab8-8a4b-7c2856dcf0a3 r/w with ordered data mode. Quota mode: none.
root@pve:~# cd /mnt/sdc-ssd-with-plp/
root@pve:/mnt/sdc-ssd-with-plp# ./diskchecker.pl -s 172.16.0.112 verify test-ssd-ext4

verifying: 0.00%

verifying: 28.12%

verifying: 85.80%

verifying: 100.00%

Total errors: 0
root@pve:/mnt/sdc-ssd-with-plp#
</pre>

==== barrier=0 ====
<pre>
root@pve:~# mount -t ext4 -o barrier=0 /dev/sdc1 /mnt/sdc-ssd-with-plp
root@pve:~# mount | grep sdc
/dev/sdc1 on /mnt/sdc-ssd-with-plp type ext4 (rw,relatime,nobarrier)
root@pve:~# cd /mnt/sdc-ssd-with-plp/
root@pve:/mnt/sdc-ssd-with-plp# ./diskchecker.pl -s 172.16.0.112 create test-ssd-ext4-nobarrier 1000

 diskchecker: running 1 sec, 0.45% coverage of 1000 MB (289 writes; 289/s)

 diskchecker: running 2 sec, 1.19% coverage of 1000 MB (768 writes; 384/s)

 diskchecker: running 3 sec, 1.90% coverage of 1000 MB (1230 writes; 410/s)

 diskchecker: running 4 sec, 2.65% coverage of 1000 MB (1721 writes; 430/s)

 diskchecker: running 5 sec, 3.47% coverage of 1000 MB (2258 writes; 451/s)

 diskchecker: running 6 sec, 4.20% coverage of 1000 MB (2743 writes; 457/s)

 diskchecker: running 7 sec, 4.92% coverage of 1000 MB (3246 writes; 463/s)

 diskchecker: running 8 sec, 5.72% coverage of 1000 MB (3783 writes; 472/s)

 diskchecker: running 9 sec, 6.43% coverage of 1000 MB (4266 writes; 474/s)

 diskchecker: running 10 sec, 7.15% coverage of 1000 MB (4756 writes; 475/s)

 diskchecker: running 11 sec, 7.90% coverage of 1000 MB (5270 writes; 479/s)

 diskchecker: running 12 sec, 8.60% coverage of 1000 MB (5758 writes; 479/s)

 diskchecker: running 13 sec, 9.43% coverage of 1000 MB (6325 writes; 486/s)

 diskchecker: running 14 sec, 10.17% coverage of 1000 MB (6862 writes; 490/s)

 diskchecker: running 15 sec, 10.86% coverage of 1000 MB (7354 writes; 490/s)

 diskchecker: running 16 sec, 11.57% coverage of 1000 MB (7870 writes; 491/s)

 diskchecker: running 17 sec, 12.21% coverage of 1000 MB (8337 writes; 490/s)

 diskchecker: running 18 sec, 12.88% coverage of 1000 MB (8821 writes; 490/s)

 diskchecker: running 19 sec, 13.50% coverage of 1000 MB (9288 writes; 488/s)

 diskchecker: running 20 sec, 14.15% coverage of 1000 MB (9755 writes; 487/s)

 diskchecker: running 21 sec, 14.76% coverage of 1000 MB (10213 writes; 486/s)

 diskchecker: running 22 sec, 15.45% coverage of 1000 MB (10719 writes; 487/s)

 diskchecker: running 23 sec, 16.09% coverage of 1000 MB (11199 writes; 486/s)

 diskchecker: running 24 sec, 16.71% coverage of 1000 MB (11681 writes; 486/s)

 diskchecker: running 25 sec, 17.52% coverage of 1000 MB (12301 writes; 492/s)

</pre>

<pre>
root@pve:~# mount -t ext4 -o barrier=0 /dev/sdc1 /mnt/sdc-ssd-with-plp
root@pve:~# dmesg | tail -n 4
[ 38.503206] vmbr0: port 1(nic1) entered forwarding state
[ 128.406477] EXT4-fs (sdc1): barriers disabled
[ 129.953659] EXT4-fs (sdc1): recovery complete
[ 129.953789] EXT4-fs (sdc1): mounted filesystem 2847a7c0-0a1e-4ab8-8a4b-7c2856dcf0a3 r/w with ordered data mode. Quota mode: none.
root@pve:~# cd /mnt/sdc-ssd-with-plp
root@pve:/mnt/sdc-ssd-with-plp# ./diskchecker.pl -s 172.16.0.112 verify test-ssd-ext4-nobarrier

verifying: 0.00%

verifying: 29.52%

verifying: 77.96%

verifying: 100.00%

Total errors: 0
root@pve:/mnt/sdc-ssd-with-plp#
</pre>

=== Test mit SSD ohne PLP ===
In diesem Test kommt eine 512 GByte Samsung 850 PRO SATA SSD zum Einsatz.

==== barrier=1 (default) ====
<pre>
root@pve:~# mkfs.ext4 /dev/sdc1
mke2fs 1.47.2 (1-Jan-2025)
Discarding device blocks: done
Creating filesystem with 125026646 4k blocks and 31260672 inodes
Filesystem UUID: b1721738-9749-4b86-9d05-d380b0337316
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

root@pve:~# mkdir /mnt/sdc-ssd-without-plp
root@pve:~# mount /dev/sdc1 /mnt/sdc-ssd-without-plp
root@pve:~# cd /mnt/sdc-ssd-without-plp
root@pve:/mnt/sdc-ssd-without-plp# wget https://gist.githubusercontent.com/bradfitz/3172656/raw/301f516a4719b48cc9c133c4ba9c864ff8eaf056/diskchecker.pl
[...]
2026-02-27 11:34:15 (140 MB/s) - 'diskchecker.pl' saved [6702/6702]

root@pve:/mnt/sdc-ssd-without-plp# chmod +x diskchecker.pl
root@pve:/mnt/sdc-ssd-without-plp# sync
root@pve:/mnt/sdc-ssd-without-plp# ./diskchecker.pl -s 172.16.0.112 create test-ssd-noplp-ext4 1000

 diskchecker: running 1 sec, 0.03% coverage of 1000 MB (22 writes; 22/s)

 diskchecker: running 2 sec, 0.33% coverage of 1000 MB (214 writes; 107/s)

 diskchecker: running 3 sec, 0.64% coverage of 1000 MB (408 writes; 136/s)

 diskchecker: running 4 sec, 0.94% coverage of 1000 MB (603 writes; 150/s)

 diskchecker: running 5 sec, 1.24% coverage of 1000 MB (803 writes; 160/s)

 diskchecker: running 6 sec, 1.54% coverage of 1000 MB (993 writes; 165/s)

 diskchecker: running 7 sec, 1.86% coverage of 1000 MB (1205 writes; 172/s)

 diskchecker: running 8 sec, 2.16% coverage of 1000 MB (1399 writes; 174/s)

 diskchecker: running 9 sec, 2.48% coverage of 1000 MB (1607 writes; 178/s)

 diskchecker: running 10 sec, 2.79% coverage of 1000 MB (1810 writes; 181/s)

 diskchecker: running 11 sec, 3.09% coverage of 1000 MB (2012 writes; 182/s)

 diskchecker: running 12 sec, 3.40% coverage of 1000 MB (2216 writes; 184/s)

 diskchecker: running 13 sec, 3.69% coverage of 1000 MB (2412 writes; 185/s)

 diskchecker: running 14 sec, 3.99% coverage of 1000 MB (2615 writes; 186/s)

 diskchecker: running 15 sec, 4.29% coverage of 1000 MB (2814 writes; 187/s)

 diskchecker: running 16 sec, 4.60% coverage of 1000 MB (3018 writes; 188/s)

 diskchecker: running 17 sec, 4.90% coverage of 1000 MB (3218 writes; 189/s)

 diskchecker: running 18 sec, 5.20% coverage of 1000 MB (3425 writes; 190/s)

 diskchecker: running 19 sec, 5.50% coverage of 1000 MB (3626 writes; 190/s)

 diskchecker: running 20 sec, 5.79% coverage of 1000 MB (3828 writes; 191/s)

 diskchecker: running 21 sec, 6.08% coverage of 1000 MB (4028 writes; 191/s)

 diskchecker: running 22 sec, 6.36% coverage of 1000 MB (4214 writes; 191/s)

 diskchecker: running 23 sec, 6.65% coverage of 1000 MB (4414 writes; 191/s)

 diskchecker: running 24 sec, 6.94% coverage of 1000 MB (4617 writes; 192/s)

 diskchecker: running 25 sec, 7.23% coverage of 1000 MB (4816 writes; 192/s)

 diskchecker: running 26 sec, 7.52% coverage of 1000 MB (5020 writes; 193/s)

client_loop: send disconnect: Broken pipe
</pre>

<pre>
werner@x390:~/bin$ ssh root@172.16.10.1
root@172.16.10.1's password:
Linux pve 6.17.2-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Feb 27 11:32:14 2026 from 172.16.0.112
root@pve:~# mount /dev/sdc1 /mnt/sdc-ssd-without-plp
root@pve:~# dme
dmesg dmeventd
root@pve:~# dmesg | tail -n 4
[ 38.593080] vmbr0: port 1(nic1) entered blocking state
[ 38.593084] vmbr0: port 1(nic1) entered forwarding state
[ 88.513484] EXT4-fs (sdc1): recovery complete
[ 88.514141] EXT4-fs (sdc1): mounted filesystem b1721738-9749-4b86-9d05-d380b0337316 r/w with ordered data mode. Quota mode: none.
root@pve:~# cd /mnt/sdc-ssd-without-plp
root@pve:/mnt/sdc-ssd-without-plp# ./diskchecker.pl -s 172.16.0.112 verify test-ssd-noplp-ext4

verifying: 0.02%

verifying: 3.74%

verifying: 100.00%

Total errors: 0
root@pve:/mnt/sdc-ssd-without-plp#
</pre>

==== barrier=0 ====
<pre>
root@pve:~# mount -t ext4 -o barrier=0 /dev/sdc1 /mnt/sdc-ssd-without-plp
root@pve:~# mount | grep sdc
/dev/sdc1 on /mnt/sdc-ssd-without-plp type ext4 (rw,relatime,nobarrier)
root@pve:~# cd /mnt/sdc-ssd-without-plp
root@pve:/mnt/sdc-ssd-without-plp# ./diskchecker.pl -s 172.16.0.112 create test-ssd-noplp-ext4-nobarrier 1000

 diskchecker: running 1 sec, 0.47% coverage of 1000 MB (303 writes; 303/s)

 diskchecker: running 2 sec, 1.26% coverage of 1000 MB (814 writes; 407/s)

 diskchecker: running 3 sec, 1.97% coverage of 1000 MB (1274 writes; 424/s)

 diskchecker: running 4 sec, 2.75% coverage of 1000 MB (1783 writes; 445/s)

 diskchecker: running 5 sec, 3.51% coverage of 1000 MB (2285 writes; 457/s)

 diskchecker: running 6 sec, 4.34% coverage of 1000 MB (2835 writes; 472/s)

 diskchecker: running 7 sec, 5.14% coverage of 1000 MB (3371 writes; 481/s)

 diskchecker: running 8 sec, 5.90% coverage of 1000 MB (3883 writes; 485/s)

 diskchecker: running 9 sec, 6.59% coverage of 1000 MB (4348 writes; 483/s)

 diskchecker: running 10 sec, 7.26% coverage of 1000 MB (4809 writes; 480/s)

 diskchecker: running 11 sec, 8.02% coverage of 1000 MB (5333 writes; 484/s)

 diskchecker: running 12 sec, 8.75% coverage of 1000 MB (5843 writes; 486/s)

 diskchecker: running 13 sec, 9.43% coverage of 1000 MB (6317 writes; 485/s)

 diskchecker: running 14 sec, 10.12% coverage of 1000 MB (6805 writes; 486/s)

 diskchecker: running 15 sec, 11.05% coverage of 1000 MB (7450 writes; 496/s)

 diskchecker: running 16 sec, 11.70% coverage of 1000 MB (7912 writes; 494/s)

 diskchecker: running 17 sec, 12.38% coverage of 1000 MB (8401 writes; 494/s)

 diskchecker: running 18 sec, 12.99% coverage of 1000 MB (8862 writes; 492/s)

 diskchecker: running 19 sec, 13.65% coverage of 1000 MB (9352 writes; 492/s)

 diskchecker: running 20 sec, 14.29% coverage of 1000 MB (9822 writes; 491/s)

 diskchecker: running 21 sec, 14.92% coverage of 1000 MB (10294 writes; 490/s)

 diskchecker: running 22 sec, 15.55% coverage of 1000 MB (10761 writes; 489/s)

 diskchecker: running 23 sec, 16.21% coverage of 1000 MB (11261 writes; 489/s)

 diskchecker: running 24 sec, 16.82% coverage of 1000 MB (11741 writes; 489/s)

client_loop: send disconnect: Broken pipe
</pre>

<pre>
werner@x390:~/bin$ ssh root@172.16.10.1
root@172.16.10.1's password:
Linux pve 6.17.2-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64
[...]
root@pve:~# mount -t ext4 -o barrier=0 /dev/sdc1 /mnt/sdc-ssd-without-plp
root@pve:~# dmesg | tail -n 4
[ 38.959022] vmbr0: port 1(nic1) entered forwarding state
[ 322.860448] EXT4-fs (sdc1): barriers disabled
[ 323.915454] EXT4-fs (sdc1): recovery complete
[ 323.915513] EXT4-fs (sdc1): mounted filesystem b1721738-9749-4b86-9d05-d380b0337316 r/w with ordered data mode. Quota mode: none.
root@pve:~# cd /mnt/sdc-ssd-with
sdc-ssd-without-plp/ sdc-ssd-with-plp/
root@pve:~# cd /mnt/sdc-ssd-without-plp
root@pve:/mnt/sdc-ssd-without-plp# ./diskchecker.pl -s 172.16.0.112 verify test-ssd-noplp-ext4
test-ssd-noplp-ext4 test-ssd-noplp-ext4-nobarrier
root@pve:/mnt/sdc-ssd-without-plp# ./diskchecker.pl -s 172.16.0.112 verify test-ssd-noplp-ext4-nobarrier

verifying: 0.01%

verifying: 49.87%

verifying: 100.00%

Total errors: 0
root@pve:/mnt/sdc-ssd-without-plp#
</pre>

== Weitere Informationen ==

Barriers and journaling filesystems (lwn.net, 21.05.2008)
ext4 General Information (docs.kernel.org/admin-guide)
https://web.archive.org/web/20200227164936/https://www.fibrevillage.com/storage/565-what-s-barriers-how-to-enable-disable-it-on-linux
IMPOSING ORDER: Working with write barriers and journaling filesystems (Linux-Magazine Issue 78, May 2007)

== Einzelnachweise ==
<references />

Autor: Werner Fischer

LCD Display von FWA-3034 unter FreeBSD und OPNsense verwenden

2026-02-17T12:59:40Z

Aranzinger:

Unter FreeBSD bzw. OPNsense wird das eingebaute Display der Appliance '''FWA-3034''' von Advantech standardmäßig nicht verwendet. Zur Verwendung des Displays kann das Community-Plugin '''lcdproc''' in Verbindung einer angepassten Konfiguration verwendet werden.

FWA-3034 von Advantech

== Testumgebung ==
Die nachfolgende Anleitung wurde in folgender Testumgebung durchgeführt:

'''Hardware''': Advantech FWA3034 mit integriertem LCD Display
'''Software''': OPNsense 26.1.2_5-amd64 (FreeBSD 14.3-RELEASE-p8s)

== Durchführung ==

Um das das serielle Display korrekt anzusteuern, muss das Plugin '''os-lcd-proc-sdelcd''' installiert werden:

Suchen Sie nach dem Community Plugin '''lcd'''

Klicken Sie unter '''System ‣ Settings ‣ Firmware''' den Reiter '''Plugins''' an'''.''' Hier muss der Haken bei '''''Show community plugins''''' gesetzt werden. Suchen Sie dann nach '''lcd'''.
Installieren Sie das Plugin
Klicken Sie auf "'''+'''" für installieren des Plugins

Nach dem das Plugin installiert wurde, muss unsere angepasste Konfigurations-Datei mit den Spezifikationen des Displays verwendet werden.

Der Dateipfad ist <code>/usr/local/etc/LCDd.conf</code>.
<pre>

[server]
DriverPath=/usr/local/lib/lcdproc/
Driver=CwLnx
Bind=127.0.0.1
Port=13666
ReportToSyslog=yes
User=nobody
Foreground=yes
Hello="== THOMAS KRENN "
Hello="== FreeBSD LCD MOD"
Hello=""
Hello=" 1234567890 "
GoodBye=""
GoodBye=""
WaitTime=10
TitleSpeed=10
ServerScreen=on
Backlight=open
ToggleRotateKey=Enter
PrevScreenKey=Up
NextScreenKey=Down

[menu]
MenuKey=Escape
EnterKey=Enter
UpKey=Up

[hd44780]
ConnectionType=lcdserializer
Device=/dev/ttyU0
Speed=19200
Keypad=yes

[CwLnx]
Device=/dev/cuau1
ConnectionType=serial
Size=20x4
Speed=19200

</pre>

=== Systemdienst zum Test aktivieren ===
Aktivieren Sie den Systemdienst mit folgendem Befehl:

<code>service LCDd onerestart</code>

== Display / Ausgabe ==
Nach Durchführung der vorherigen Schritte, sollte folgendes Ergebnis zu sehen sein:

Autor: Wilfried Seifert

Wilfried Seifert, tätig in der Abteilung Systems Engineering bei Thomas-Krenn, ist in seinem Arbeitsbereich für die System-/Prototypenentwicklung sowie Softwaredeployment / Rollout unterschiedlicher Architekturen zuständig. LPIC 3 zertifiziert, beschäftigt sich u.a. mit Aufbau / Programmierung Embedded (x64/ARM) Systemen.

OPNsense 26.1 Firewall Regel Migration

2026-02-13T10:27:34Z

Aranzinger:

Mit dem Release der Version OPNsense '''26.1''' wurde weiter an der '''schrittweisen Migration aller Konfigurationsmenüs hinzu MVC/API Code''' gearbeitet. Der Bereich der Firewall-Regeln wurde mit diesem Release um ein MVC/API Konfigurationsmenü ''Firewall → Rules [new]'' erweitert. Das bisherige Menü unter ''Firewall → Rules'' bleibt als legacy parallel bestehen und erhält einen Migrationsassistenten. Dieser Artikel zeigt, wie Sie diese '''Migration der Firewall Regeln auf das neue Firewall Konfigurationsmenü''' vornehmen.

'''Bitte beachten:''' Diese Migration klappte bei verschiedenen OPNsense Firewalls einwandfrei, aber es gibt keine Garantie dass diese Migration jederzeit problemfrei funktioniert. Ein Backup der Konfiguration ist unerlässlich.

Hier geht es zu unseren OPNSense Firewalls im Onlineshop von Thomas-Krenn

== Vorbereitungen zur Migration der Regeln ==
Bevor die Regeln exportiert und dann im neuen Menü importiert werden, sollten zur Sicherheit die vorgeschlagenen Schritte befolgt werden die der Migrationsassistent anbietet.
<gallery>
File:OPNsense-26.1-Firewall-rules-migration-001.png|Starten Sie den Migrationsprozess im Menü ''Firewall → Rules → Migration assistant''.
File:OPNsense-26.1-Firewall-rules-migration-002.png|Wenn Sie eine ZFS-basierte Installation der OPNsense Firewall betreiben, können Sie im Menü ''System → Snapshots'' einen Snapshot des Systems vornehmen.
File:OPNsense-26.1-Firewall-rules-migration-003.png|Klicken Sie auf das orange Plus um einen neuen Snapshot zu erstellen.
File:OPNsense-26.1-Firewall-rules-migration-004.png|Klicken Sie auf ''Save''.
File:OPNsense-26.1-Firewall-rules-migration-005.png|Der Snapshot wurde angelegt.
File:OPNsense-26.1-Firewall-rules-migration-006.png|Alternativ können Sie auch die Konfiguration sichern, dies geht über das Menü ''System → Configuration → Backups''.
File:OPNsense-26.1-Firewall-rules-migration-007.png|Durch klicken auf ''Download configuration'' können Sie die Konfiguration als CSV-Datei herunterladen.
File:OPNsense-26.1-Firewall-rules-migration-008.png|Prüfen Sie im Menü ''Firewall → Settings → Advanced'' ob die Variable ''Disable anti-lockout'' deaktiviert ist.
</gallery>

== Bestehende Firewall Regeln exportieren ==
Der eigentliche Migrationsprozess startet mit diesem Schritt, die Regeln werden nun in ein CSV-Format exportiert.

<gallery>
File:OPNsense-26.1-Firewall-rules-migration-009.png|Im Menü ''Firewall → Rules → Migration assistant'' können Sie mit dem Schritt 3 die bestehenden Firewall Regeln exportieren.
File:OPNsense-26.1-Firewall-rules-migration-010.png|Diese bestehenden Regeln werden als CSV-Datei heruntergeladen, Sie können diese in diesem Zuge ändern.
</gallery>

== Exportierte Regeln importieren ==
In diesem finalen Schritt wird nun die zuvor heruntergeladene CSV-Datei im neuen Firewall Regelmenü importiert und abschließend werden die alten Firewall Regeln gelöscht.

<gallery>
File:OPNsense-26.1-Firewall-rules-migration-011.png|Im Schritt 4 des Migrationsassistenten können Sie diese nun wieder für das neue Konfigurationsmenü importieren.
File:OPNsense-26.1-Firewall-rules-migration-012.png|Sie werden zu dem neuen Firewall Regelmenü verlinkt. Klicken Sie rechts auf das Icon ''Import csv''.
File:OPNsense-26.1-Firewall-rules-migration-013.png|Wählen Sie durch klicken auf ''Choose File'' die kürzlich heruntergeladene CSV-Datei aus.
File:OPNsense-26.1-Firewall-rules-migration-014.png|Klicken Sie auf den Haken um die Regeln zu importieren.
File:OPNsense-26.1-Firewall-rules-migration-015.png|Die Regeln wurden importiert, klicken Sie rechts oben auf das X um das Menü zu schließen.
File:OPNsense-26.1-Firewall-rules-migration-016.png|Abschließend müssen Sie nur noch auf ''Apply'' klicken, die Regeln sind dann im neuen Menü hinterlegt und aktiviert.
File:OPNsense-26.1-Firewall-rules-migration-017.png|Die bestehenden Legacy Regeln können nun bequem auf einmal entfernt werden, klicken Sie auf den Punkt ''Remove all legacy rules''.
File:OPNsense-26.1-Firewall-rules-migration-018.png|Klicken sie auf ''Yes''.
File:OPNsense-26.1-Firewall-rules-migration-019.png|Sie werden zum neuen Firewall Menü geleitet, klicken Sie auf ''Apply''. Die Migration ist nun erledigt.
</gallery>

Autor: Thomas Niedermeier

LSA LSI Storage Authority Software

2026-02-12T12:45:50Z

Aranzinger:

In diesem Artikel wird beschrieben, wie Sie die '''LSA LSI Storage Authority Software''' von Broadcom installieren und konfigurieren.

== Voraussetzungen ==

Server mit einem MegaRAID Controller
Microsoft Windows Server
Lokale Administratorrechte auf dem System

== Was ist LSA? ==

Die '''LSI Storage Authority (LSA)''' ist eine webbasierte Management-Software von Broadcom zur Überwachung und Verwaltung von '''MegaRAID-Controllern''' unter Windows und Linux.

Über die LSA-Weboberfläche lassen sich unter anderem folgende Informationen und Funktionen bereitstellen:

Statusübersicht aller installierten RAID-Controller
Überwachung von physischen und virtuellen Laufwerken
Sofortige Erstellung von RAIDs
Anzeige von Warnungen, Fehlern und Ereignissen
Firmware- und Treiberinformationen & Updates
Konfiguration von E-Mail-Benachrichtigungen bei Vorfällen

Die Weboberfläche wird lokal auf dem Server bereitgestellt und standardmäßig über den Browser aufgerufen.

== Installation ==
<gallery>
download.png | '''Schritt 1:''' Zunächst wird die '''LSA (LSI Storage Authority)''' von der Broadcom-Website heruntergeladen: » Hier herunterladen «

lsa-lsi-installation-01.png | '''Schritt 2:''' Nach dem Download liegt die Software als Archiv vor. Dieses kann per Rechtsklick über '''Alle extrahieren…''' entpackt werden.

lsa-lsi-installation-02.png | '''Schritt 3:''' Nach dem Entpacken wird ein Ordner erstellt. Darin befindet sich die Datei '''setup.exe''', über welche die Installation gestartet wird. '''Hinweis:''' Nach der Installation kann es zu einem bekannten Anmeldefehler mit dem '''Error Code 49 (Invalid Credentials)''' kommen. In diesem Fall ist der folgende Artikel zu beachten: LSI Storage Authority Error Code 49 Invalid Credentials.

lsa-lsi-installation-03.png | '''Schritt 4:''' Nach erfolgreicher Installation empfiehlt es sich, den LSA-Dienst neu zu starten, um einen vollständigen Systemneustart zu vermeiden. Dies kann direkt über den '''Task-Manager''' erfolgen.

lsa-lsi-installation-04.png | '''Schritt 5:''' Im Reiter '''Dienste''' den Dienst '''LSAService''' suchen, per Rechtsklick auswählen und '''Neu starten''' ausführen.

lsa-lsi-installation-05.png | '''Schritt 6:''' Anschließend kann die LSA über die Verknüpfung '''Launch LSA''' gestartet werden. Der Zugriff erfolgt anschließend automatisch über den Standard-Webbrowser.
</gallery>

== RAID erstellen ==
In diesem Abschnitt wird beschrieben, wie über die Weboberfläche der '''LSI Storage Authority (LSA)''' ein RAID-Verbund auf einem MegaRAID Controller erstellt wird. Die Erstellung erfolgt über die erweiterte Konfiguration und führt Schritt für Schritt durch die Auswahl des RAID-Levels, der physischen Laufwerke sowie die Anlage des Virtual Drives.

'''Hinweis: Bei der Erstellung eines neuen RAID-Verbunds werden alle auf den ausgewählten Festplatten vorhandenen Daten gelöscht.'''
<gallery>
lsa-lsi-raid-01.png | '''Schritt 1:''' In der LSA-Weboberfläche befindet sich auf der rechten Seite im Bereich '''Controller Actions''' der Punkt '''Configure''', welcher ein weiteres Dropdown-Menü öffnet.

lsa-lsi-raid-02.png | '''Schritt 2:''' In dem geöffneten Dropdown-Menü wird der Punkt '''Advanced Configuration''' ausgewählt.

lsa-lsi-raid-03.png | '''Schritt 3:''' In der erweiterten Konfiguration kann zwischen den verschiedenen verfügbaren RAID-Leveln gewählt werden, in diesem Beispiel wird ein '''RAID 1''' erstellt.

lsa-lsi-raid-04.png | '''Schritt 4:''' Mit einem Klick auf '''Next''' gelangt man in das nächste Menü, in dem die physischen Laufwerke sowie die virtuellen Laufwerke konfiguriert werden.

lsa-lsi-raid-05.png | '''Schritt 5:''' Zunächst müssen die physischen Festplatten ausgewählt werden, die für das RAID verwendet werden sollen.

lsa-lsi-raid-06.png | '''Schritt 6:''' Wählen Sie die gewünschten Festplatten aus und bestätigen Sie die Auswahl mit einem Klick auf '''Add Physical Drives'''.

lsa-lsi-raid-07.png | '''Schritt 7:''' Anschließend wird ein '''Virtual Drive''' erstellt, welches später vom Betriebssystem genutzt wird.

lsa-lsi-raid-08.png | '''Schritt 8:''' Nachdem das Virtual Drive erstellt wurde, kann das RAID mit einem Klick auf '''Finish''' angelegt werden.

lsa-lsi-raid-09.png | '''Schritt 9:''' Nach erfolgreicher Erstellung des RAIDs erscheint eine entsprechende Bestätigung in der LSA-Weboberfläche.

lsa-lsi-raid-10.png | '''Schritt 10:''' Im Controller-Menü wird nun das neu erstellte Virtual Drive sowie der zugehörige Drive Group Status angezeigt.
</gallery>

== Firmware Update ==
Ein Firmware-Update eines MegaRAID Controllers kann komfortabel direkt über die Weboberfläche der '''LSI Storage Authority (LSA)''' durchgeführt werden.

<gallery>
download.png | '''Schritt 1:''' Zunächst wird die aktuellste passende '''Firmware''' von der » Thomas-Krenn Downloadseite « heruntergeladen, hierbei muss der verbaute Controller zuvor unter '''Produkt auswählen''' korrekt gefiltert werden.

Unpack-archive-icon.png | '''Schritt 2:''' Das heruntergeladene Archiv wird entpackt, im entpackten Ordner befindet sich die für das Update benötigte '''.rom'''-Datei.

lsa-lsi-firmware-update-00.png | '''Schritt 3:''' In der LSA-Weboberfläche befindet sich auf der rechten Seite im Bereich '''Controller Actions''' der Punkt '''Update Firmware''', über welchen das Firmware-Update-Menü geöffnet wird.

lsa-lsi-firmware-update-01.png | '''Schritt 4:''' Mit einem Klick auf '''Browse''' öffnet sich der Datei-Explorer, hier wird die zuvor entpackte '''.rom'''-Datei ausgewählt und mit '''Öffnen''' bestätigt.

lsa-lsi-firmware-update-02.png | '''Schritt 5:''' Nach dem Laden der Datei kann das Update über den Button '''Update''' vorbereitet werden.

lsa-lsi-firmware-update-03.png | '''Schritt 6:''' Zur Kontrolle wird ein Versionsvergleich zwischen der aktuell installierten und der ausgewählten Firmware angezeigt, darunter befindet sich die finale Bestätigung für das Update.

lsa-lsi-firmware-update-04.png | '''Schritt 7:''' Durch Aktivieren der Checkbox '''Confirm''' und einen Klick auf '''Flash Firmware''' wird das Firmware-Update gestartet.
</gallery>

Nach erfolgreichem Abschluss des Updates kann in der Regel sofort weiter mit dem Controller gearbeitet werden, ein Neustart des Systems ist nur in seltenen Fällen erforderlich.

== Einzelne Festplatte in JBOD umwandeln ==
In diesem Abschnitt wird beschrieben, wie eine einzelne physische Festplatte über die Weboberfläche der '''LSI Storage Authority (LSA)''' in den Modus '''JBOD (Just a Bunch Of Disks)''' versetzt wird. Dadurch kann die Festplatte ohne RAID-Verbund direkt an das Betriebssystem durchgereicht werden. Zusätzlich wird gezeigt, wie eine zuvor als JBOD konfigurierte Festplatte wieder in den Zustand '''Unconfigured Good''' zurückversetzt wird, um sie erneut in einem RAID-Verbund verwenden zu können.
<gallery>
lsa-lsi-jbod-single-01.png | '''Schritt 1:''' In den Einstellungen des Controllers werden alle nicht konfigurierten Festplatten unter '''Unconfigured Drives''' angezeigt.
lsa-lsi-jbod-single-02.png | '''Schritt 2:''' Die gewünschte Festplatte wird ausgewählt und anschließend über die rechte Seitenleiste unter '''Element Actions''' mit '''Make JBOD''' in den JBOD-Modus umgewandelt.
lsa-lsi-jbod-single-03.png | '''Schritt 3:''' Der Vorgang dauert nur wenige Sekunden. Nach erfolgreichem Abschluss wird die Festplatte im Bereich '''JBOD''' angezeigt und zusätzlich erscheint der Hinweis '''Action Successful'''.
</gallery>

Soll eine JBOD-Festplatte wieder für einen RAID-Verbund verwendet werden, kann diese wie folgt zurückgesetzt werden:

<gallery>
lsa-lsi-jbod-single-04.png | '''Schritt 1:''' Die JBOD-Festplatte wird ausgewählt und über die rechte Seitenleiste mit '''Make Unconfigured Good''' zurückgesetzt.
lsa-lsi-jbod-single-05.png | '''Schritt 2:''' Die Aktion wird durch Aktivieren der Checkbox '''Confirm''' und einem Klick auf '''Yes, Make Unconfigured Good''' bestätigt.
</gallery>

== Alle Festplatten in JBOD umwandeln ==
In diesem Abschnitt wird beschrieben, wie alle am Controller angeschlossenen Festplatten automatisch als '''JBOD''' verwendet werden können. Hierzu wird die '''Personalität des Controllers''' von '''RAID''' auf '''JBOD''' umgestellt, wodurch sämtliche Laufwerke ohne RAID-Konfiguration direkt an das Betriebssystem durchgereicht werden.

<gallery>
lsa-lsi-jbod-01.png | '''Step 1:''' In der Weboberfläche der LSI Storage Authority befindet sich auf der rechten Seite der Bereich '''Controller Actions'''. Dort wird '''Personality Management''' ausgewählt.
lsa-lsi-jbod-02.png | '''Schritt 2:''' Im Menü '''Select Personality''' kann zwischen '''RAID''' und '''JBOD''' gewählt werden. Hier muss '''JBOD''' ausgewählt werden.
lsa-lsi-jbod-03.png | '''Schritt 3:''' Mit einem Klick auf '''Change''' wird die Personalität des Controllers geändert und alle Festplatten werden automatisch als JBOD bereitgestellt.
</gallery>

== Email Notification einrichten ==
Für einen zuverlässigen Betrieb wird empfohlen, die E-Mail-Benachrichtigungen in der LSA zu konfigurieren, um bei RAID-Fehlern oder kritischen Ereignissen automatisch informiert zu werden.

Dabei sollten insbesondere folgende Punkte beachtet werden:

Verwendung eines erreichbaren SMTP-Servers
Aktivierung von SSL/TLS, sofern vom Mailserver unterstützt
Hinterlegung mindestens einer Empfängeradresse
Test der Konfiguration über '''Test Configuration'''

Nur bei korrekt eingerichteter E-Mail-Benachrichtigung ist eine frühzeitige Reaktion auf Hardware-Fehler gewährleistet.
<gallery>
lsa-lsi-installation-07.png | '''Schritt 1:''' Nach dem Öffnen der Weboberfläche der LSI Storage Authority kann die Anmeldung über '''Sign In''' erfolgen. Als Benutzername wird der aktuelle '''Windows Benutzername''' verwendet, das Passwort entspricht dem lokalen Systemkennwort.

lsa-lsi-installation-08.png | '''Schritt 2:''' Nach erfolgreicher Anmeldung wird rechts oben der aktuell angemeldete Benutzer angezeigt. Durch einen Linksklick öffnet sich ein Dropdown-Menü.

lsa-lsi-installation-09.png | '''Schritt 3:''' In diesem Dropdown-Menü wählen Sie den Punkt '''Settings''' aus, um die Konfiguration zu öffnen.

lsa-lsi-installation-10.png | '''Schritt 4:''' In den Einstellungen stehen unter anderem die Konfiguration der '''Alert Filter''' sowie die '''Mail Server'''-Einstellungen zur Verfügung.

lsa-lsi-installation-11.png | '''Schritt 5:''' Im Menü '''Mail Server''' können die SMTP-Einstellungen entsprechend der eigenen Mailserver-Konfiguration vorgenommen werden. Über den Button '''Test Configuration''' lässt sich prüfen, ob der E-Mail-Versand erfolgreich funktioniert.

lsa-lsi-installation-12.png | '''Schritt 6:''' Nach Abschluss der Konfiguration werden die Einstellungen über '''Save Settings''' gespeichert. Anschließend werden E-Mail-Benachrichtigungen bei entsprechenden Ereignissen automatisch versendet.
</gallery>

== Bekannte Fehler ==

Anmeldefehler beheben

== Abschluss ==

Nach erfolgreicher Installation und Konfiguration bietet die LSI Storage Authority eine zentrale und übersichtliche Möglichkeit zur Überwachung von MegaRAID-Controllern.
Insbesondere in produktiven Umgebungen trägt eine korrekt konfigurierte LSA maßgeblich zur Betriebssicherheit und schnellen Fehlererkennung bei.

Autor: Adrian Zillner

Adrian Zillner ist im Technical Service bei der Thomas-Krenn AG tätig. Er ist für das Betreuen von Kunden und Beantworten von Fragen bei technischen Problemen zuständig.

Sicherheitshinweise zu AMD-SB-4013

2026-02-12T11:17:39Z

Aranzinger:

Am '''10. Februar 2025''' wurde von AMD das Security Bulletin AMD-SB-4013 <ref>AMD Athlon™ and AMD Ryzen™ Processor Vulnerabilities – February 2026 (www.amd.com/en/resources/product-security)</ref> mit einer Vielzahl von Sicherheitslücken veröffentlicht.

== Betroffene Systeme ==

Systeme mit AMD Ryzen Threadripper PRO 3000WX Prozessoren
Systeme mit AMD Ryzen Threadripper PRO 5000WX Prozessoren
Systeme mit AMD Ryzen Threadripper 7000 / PRO 7000WX Prozessoren
Systeme mit AMD Ryzen Threadripper 9000 / PRO 9000WX Prozessoren

== Problemlösung ==

Hier eine tabellarische Aufstellung der entsprechenden CVEs und Maßnahmen zur Behebung, für die jeweilige Threadripper Generation, falls vorhanden.

'''AMD Ryzen Threadripper PRO 3000WX'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2021-26381	7.1 (Hoch)	ChagallWSPI-sWRX8 1.0.0.2 (2022-01-20) CastlePeakWSPI-sWRX8 1.0.0.9 (2022-01-20)
CVE-2024-21961	6.0 (Mittel)	Kein Fix geplant
CVE-2024-36355	7.0 (Hoch)	ChagallWSPI-sWRX8-1.0.0.B (2024-12-24) CastlePeakWSPI-sWRX8 1.0.0.G (2024-12-30)
CVE-2025-29949	4.8 (Mittel)	ChagallWSPI-sWRX8 1.0.0.C (2025-04-03) CastlePeakWSPI-sWRX8 1.0.0.H (2025-03-31)
CVE-2025-29950	7.1 (Hoch)	ChagallWSPI-sWRX8 1.0.0.C (2025-04-03) CastlePeakWSPI-sWRX8 1.0.0.I (2025-10-27)
CVE-2025-52533	8.7 (Hoch)	Behebung in Key Distribution Server (KDS)

'''AMD Ryzen Threadripper PRO 5000WX'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2021-26381	7.1 (Hoch)	ChagallWSPI-sWRX8 1.0.0.1 (2021-11-10)
CVE-2024-36355	7.0 (Hoch)	ChagallWSPI-sWRX8-1.0.0.B (2024-12-24)
CVE-2025-29949	4.8 (Mittel)	ChagallWSPI-sWRX8 1.0.0.C (2025-04-03)
CVE-2025-29950	7.1 (Hoch)	ChagallWSPI-sWRX8 1.0.0.C (2025-04-03)
CVE-2025-52533	8.7 (Hoch)	Behebung in Key Distribution Server (KDS)

'''AMD Ryzen Threadripper 7000'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2024-36310	4.6 (Mittel)	StormPeakPI-SP6_1.1.0.0j (2025-06-11)
CVE-2024-36355	7.0 (Hoch)	StormPeakPI-SP6 1.1.0.0i (2024-12-18)
CVE-2025-29950	7.1 (Hoch)	ShimadaPeakPI-SP6_1.0.0.1 (2025-05-07)
CVE-2025-52533	8.7 (Hoch)	Behebung in Key Distribution Server (KDS)

'''AMD Ryzen Threadripper PRO 7000WX'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2024-36310	4.6 (Mittel)	StormPeakPI-SP6_1.0.0.1l (2025-06-18) StormPeakPI-SP6_1.1.0.0j (2025-06-11)
CVE-2024-36355	7.0 (Hoch)	StormPeakPI-SP6 1.0.0.1k (2024-12-20) StormPeakPI-SP6 1.1.0.0i (2024-12-18)
CVE-2025-29950	7.1 (Hoch)	ShimadaPeakPI-SP6_1.0.0.1 (2025-05-07) StormPeakPI-SP6_1.0.0.1l (2025-06-18) StormPeakPI-SP6_1.1.0.0j (2025-06-11)
CVE-2025-52533	8.7 (Hoch)	Behebung in Key Distribution Server (KDS)

'''AMD Ryzen Threadripper 9000'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2025-29950	7.1 (Hoch)	ShimadaPeakPI-SP6_1.0.0.1 (2025-05-07)
CVE-2025-54514	4.8 (Mittel)	ShimadaPeakPI-SP6_1.0.0.1b (2025-07-28)

'''AMD Ryzen Threadripper PRO 9000WX'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''
CVE-2024-21961	6.0 (Mittel)	Kein Fix geplant
CVE-2024-36355	7.0 (Hoch)	ComboAM5 1.1.0.3c (2025-01-27) ComboAM5 1.2.0.3d (2025-04-29)
CVE-2025-29950	7.1 (Hoch)	ShimadaPeakPI-SP6_1.0.0.1 (2025-05-07)
CVE-2025-54514	4.8 (Mittel)	ShimadaPeakPI-SP6_1.0.0.1b (2025-07-28)
CVE-2025-52533	8.7 (Hoch)	Behebung in Key Distribution Server (KDS)

Autor: Thomas-Krenn.AG

Sicherheitshinweise zu AMD-SB-3023

2026-02-12T11:16:25Z

Aranzinger:

Am '''10. Februar 2025''' wurde von AMD das Security Bulletin AMD-SB-3023<ref>AMD EPYC™ and AMD EPYC™ Embedded Series Processor Vulnerabilities – February 2026 (www.amd.com/en/resources/product-security)</ref> mit einer Vielzahl von Sicherheitslücken veröffentlicht.

== Betroffene Systeme ==

Systeme mit "Zen 1" AMD EPYC 7001 Naples Prozessoren
Systeme mit "Zen 2" AMD EPYC 7002 Rome Prozessoren
Systeme mit "Zen 3" AMD EPYC 7003 Milan Prozessoren
Systeme mit "Zen 4" AMD EPYC 9004 Genoa und Bergamo & 8004 Siena Prozessoren
Systeme mit "Zen 5" AMD EPYC 9005 Turin Prozessoren

== Problemlösung ==

Hier eine tabellarische Aufstellung der entsprechenden CVEs und Maßnahmen zur Behebung, für die jeweilige EPYC Generation, falls vorhanden.

'''AMD EPYC 7001 Naples'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	µcode
CVE-2025-29950	7.1 (Hoch)	NaplesPI 1.0.0.R (2025-07-31)	N/A	N/A
CVE-2025-52533	8.7 (Hoch)	Kein Fix geplant	N/A	N/A

'''AMD EPYC 7002 Rome'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	µcode
CVE-2025-29950	7.1 (Hoch)	RomePI 1.0.0.N (2025-08-14)	N/A	N/A
CVE-2024-21961	6.0 (Mittel)	Workaround in Custom BIOS Settings (CBS)	N/A	N/A
CVE-2025-52533	8.7 (Hoch)	Kein Fix geplant	N/A	N/A

'''AMD EPYC 7003 Milan:'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	µcode
CVE-2025-48514	4.0 (Mittel)	MilanPI 1.0.0.H (2025-09-04)	SEV FW 1.37.23 SPL[SEV]=0x1B mitigation bit=3	B1:0x0A0011DE B2:0x0A001247
CVE-2025-29939	6.9 (Mittel)	MilanPI 1.0.0.H (2025-09-04)	SEV FW 1.37.23 SPL[SEV]=0x1B mitigation bit=3	N/A
CVE-2025-48509	1.8 (Niedrig)	MilanPI 1.0.0.H (2025-09-04)	SEV FW 1.37.23 SPL[SEV]=0x1B mitigation bit=3	N/A
CVE-2025-0031	4.6 (Mittel)	MilanPI 1.0.0.H (2025-09-04)	SEV FW 1.37.20 SPL[SEV]=0x1A	N/A
CVE-2025-52536	6.7 (Mittel)	MilanPI 1.0.0.H (2025-09-04)	SEV FW 1.37.1F SPL[SEV]=0x1A	N/A
CVE-2025-29950	7.1 (Hoch)	MilanPI 1.0.0.H (2025-09-04)	N/A	N/A
CVE-2025-52533	3.8 (Niedrig)	MilanPI 1.0.0.G (2025-01-30)	N/A	N/A

'''AMD EPYC 8004 Siena:'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	µcode
CVE-2025-48514	4.0 (Mittel)	GenoaPI 1.0.0.H (2025-12-15)	SEV FW 1.37.31 SPL[SEV]=0x1B mitigation bit=3	A2:0x0AA0021B
CVE-2025-29939	6.9 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.31 SPL[SEV]=0x1B mitigation bit 0	N/A
CVE-2025-48509	1.8 (Niedrig)	GenoaPI 1.0.0.F (2025-03-28)	SEV FW 1.37.2A SPL[SEV]=0x18 mitigation bit=3	N/A
CVE-2025-0031	4.6 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.2B SPL[SEV]=0x19	N/A
CVE-2025-52536	6.7 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.2B SPL[SEV]=0x19	N/A
CVE-2024-21953	5.9 (Mittel)	GenoaPI 1.0.0.F (2025-03-28)	SEV FW 1.37.2A SPL[SEV]=0x18	N/A

'''AMD EPYC 9004 Bergamo / Siena:'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	µcode
CVE-2025-48514	4.0 (Mittel)	GenoaPI 1.0.0.H (2025-12-15)	SEV FW 1.37.31 SPL[SEV]=0x1B mitigation bit=3	A2:0x0AA0021B
CVE-2025-29939	6.9 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.31 SPL[SEV]=0x1B mitigation bit 3	N/A
CVE-2025-48509	1.8 (Niedrig)	GenoaPI 1.0.0.F (2025-03-28)	SEV FW 1.37.2A SPL[SEV]=0x18 mitigation bit=3	N/A
CVE-2025-0031	4.6 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.2B SPL[SEV]=0x19	N/A
CVE-2025-52536	6.7 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.2B SPL[SEV]=0x19	N/A
CVE-2025-29950	7.1 (Hoch)	GenoaPI 1.0.0.G (2025-06-27)	N/A	N/A

'''AMD EPYC 9004 Genoa:'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	µcode
CVE-2025-48514	4.0 (Mittel)	GenoaPI 1.0.0.H (2025-12-15)	SEV FW 1.37.31 SPL[SEV]=0x1B	B1: 0x0A101156 B2:0x0A101251
CVE-2025-29939	6.9 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.31 SPL[SEV]=0x1B	N/A
CVE-2025-52536	6.7 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.3D SPL[SEV]=0x2	N/A
CVE-2025-48509	1.8 (Niedrig)	GenoaPI 1.0.0.F (2025-03-28)	SEV FW 1.37.2A SPL[SEV]=0x18 mitigation bit=3	N/A
CVE-2025-0031	4.6 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.2A SPL[SEV]=0x18	N/A
CVE-2025-52536	6.7 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	SEV FW 1.37.2B SPL[SEV]=0x19	N/A
CVE-2025-29950	7.1 (Hoch)	GenoaPI 1.0.0.G (2025-06-27)	N/A	N/A
CVE-2024-36310	4.6 (Mittel)	GenoaPI 1.0.0.G (2025-06-27)	N/A	N/A
CVE-2024-36355	7.0 (Hoch)	GenoaPI 1.0.0.E (2024-12-16)	N/A	N/A

'''AMD EPYC 9005 Turin / Turin Dense'''


Sicherheitslücke	Gefährdungspotential:	'''AGESA Version'''	SEV FW	µcode
CVE-2025-48514	4.0 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	SEV FW 1.37.41 SPL[SEV]=0x4 mitigation bit=3	C1:0x0B002151 Dense B0: 0x0B10104E
CVE-2025-54514	4.8 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	N/A	BRH C1: 0x0B002151 BRHD B0: 0x0B10104E
CVE-2025-29939	6.9 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	SEV FW 1.37.41 SPL[SEV]=0x4 mitigation bit=3	N/A
CVE-2025-29946	4.5 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	SEV FW 1.37.41 SPL[SEV]=0x4 mitigation bit=3	N/A
CVE-2025-29948	5.9 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	SEV FW 1.37.41 SPL[SEV]=0x4 mitigation bit=3	N/A
CVE-2025-29952	5.9 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	SEV FW 1.37.41 SPL[SEV]=0x4 mitigation bit=3	N/A
CVE-2025-48517	4.6 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	SEV FW 1.37.41 SPL[SEV]=0x4 mitigation bit=3	N/A
CVE-2025-52536	6.7 (Mittel)	TurinPI 1.0.0.5 (2025-04-18)	SEV FW 1.37.3D SPL[SEV]=0x2	N/A
CVE-2025-48509	1.8 (Niedrig)	TurinPI 1.0.0.5 (2025-04-18)	SEV FW 1.37.3D SPL[SEV]=0x2	N/A
CVE-2025-0031	4.6 (Mittel)	TurinPI 1.0.0.5 (2025-04-18)	SEV FW 1.37.3D SPL[SEV]=0x2	N/A
CVE-2025-0029	1.8 (Niedrig)	TurinPI 1.0.0.5 (2025-04-18)	N/A	N/A
CVE-2025-29950	7.1 (Hoch)	TurinPI 1.0.0.6 (2025-06-30)	N/A	N/A
CVE-2024-36310	4.6 (Mittel)	TurinPI 1.0.0.4 (2025-03-04)	N/A	N/A
CVE-2025-0012	6.8 (Mittel)	TurinPI 1.0.0.4 (2025-03-04)	N/A	C1: 0x0B002147 Dense B0: 0x0B101047
CVE-2025-52534 Nur Turin Dense	5.3 (Mittel)	TurinPI 1.0.0.6 (2025-06-30)	N/A	Dense B0: 0x0B10104E

Supermicro hat ein Security Bulletin zu den Sicherheitslücken veröffentlicht. Eine Liste mit BIOS-Versionen der jeweiligen Mainboards, mit einer AGESA-Version, um die Lücken zu schließen, ist auch enthalten. Nachfolgend ein Auszug aus dieser Tabelle, in der alle Mainboards aufgeführt sind, die von Thomas Krenn angeboten werden: <ref>AMD Security Bulletin AMD-SB-3023, Februar 2026 (www.supermicro.com)</ref>


AMD Motherboard	'''BIOS Version'''
H11 - EPYC 7001 / 7002	3.5
H12SSW-iN/NT	3.5
H12SSL-i/C/CT/NT	3.5
H12DSi-N6/NT6	3.5
H13SSW	3.8
H13SSL-N/NC	3.8

Autor: Thomas-Krenn.AG

Sicherheitshinweise zu Intel Produkten 2026.1 IPU

2026-02-12T08:35:49Z

Aranzinger:

Im Februar '''2026''' wurden von Intel im Rahmen des IPU 2026.1 neue Security Advisories (Sicherheitshinweise) zu verschiedenen Intel-Produkten veröffentlicht. Manche dieser Sicherheitshinweise erfordern '''Firmware Updates'''.

Intel Security Advisory	Titel	Betroffene Systeme
INTEL-SA-01171	Intel® Ethernet Adapters 800 Series Advisory	(siehe Intel-SA)
INTEL-SA-01412	Intel® Server Board and Intel® Server System Firmware Update Utility Advisory
INTEL-SA-01401	Intel® Server Firmware Advisory
INTEL-SA-01397	2026.1 IPU, Intel® Trust Domain Extensions (Intel® TDX) module Advisory
INTEL-SA-01396	2026.1 IPU, Intel® Processor Firmware Advisory
INTEL-SA-01315	2026.1 IPU, Intel® Chipset Firmware Advisory
INTEL-SA-01314	2025.4 IPU, Intel® TDX Module Advisory
INTEL-SA-01406	Intel® Quick Assist Technology (Intel® QAT) Advisory
INTEL-SA-01403	Intel® NPU Driver Advisory

Intel CPU Microcode 20260210 Brings Security Updates & Functional Fixes (phoronix.com, 10.02.2026)
Security Center (www.intel.com)
Intel Platform Update (IPU) Update 2026.1 February 2026 (supermicro.com, 10.02.2026)

Autor: Thomas-Krenn.AG

Tape Library/Autoloader in PBS einbinden

2026-01-29T15:09:34Z

Sbohn:

Dieser Artikel zeigt Ihnen, wie Sie eine Tape Library bzw. einen Autoloader in den Proxmox Backup Server integrieren können.

== Ausgangssituation ==
Folgende Hard- und Softwarekomponenten werden für die Einbindung benötigt:

Proxmox Backup Server mit eingebautem HBA für die Verbindung zwischen PBS und Tape Library
Quantum Superloader 3 (Autoloader)
Verkabelung zwischen Tape Library / Autoloader und dem Proxmox Backup Server

== Konfiguration ==

Folgende Schritte müssen durchgeführt werden, damit die Tape Library hinzugefügt werden kann:

<gallery>
Datei:Tape Backup PBS Changer.png|Zu Beginn muss der Changer zum PBS hinzugefügt werden. Dazu muss unter "'''Tape Library'''" auf "'''Changers'''" und anschließend auf "'''Add'''" geklickt werden. Nun kann der ein Name für den Changer vergeben werden, sowie auch der ISCSI-Pfad, dieser sollte bei korrekter Verkabelung automatisch hinzugefügt werden. Anschließend kann der Changer durch einen Klick auf "'''Add'''" hinzugefügt werden.
Datei:Tape Backup PBS Drives.png|Anschließend müssen die Drives hinzugefügt werden, klicken Sie dazu unter "'''Drive'''" auf "'''Add'''". Auch hier kann wieder ein Name vergeben werden, sowie der Changer und der Pfad ausgewählt werden. Klicken Sie auf "'''Add'''" um die Konfiguration zu übernehmen.
Datei:Tape Backup PBS Encryption Key.png|Als optionale Möglichkeit, kann unter "'''Encryption Keys'''" ein Key für die spätere Konfiguration der Media Pools erstellt werden.
Datei:Tape Backup PBS Media Pools.png|Folgend kann der Media Pool erstellt werden, gehen Sie dazu unter "'''Media Pools'''" auf "'''Add'''". Folgend vergeben Sie einen "'''Namen'''" und konfigurieren Sie "'''Allocation & Retention Policy'''", sowie ggf. den Encryption Key.
Datei:Tape Backup PBS Label Media.png|Zusätzlich werden die Medien nun gelabelt. Gehen Sie dazu unter "'''Inventory'''" "'''Add Tape'''" und konfigurieren Sie "'''Drive'''" "'''Label'''" und "'''Media Pool'''".
Datei:Tape Backup PBS Backup Job.png|Nun muss nur noch der Backup-Job auf das Tape erstellt werden. Gehen Sie dazu unter "'''Backup Jobs'''" auf "'''Add'''" und konfigurieren Sie den Backup Job nach Ihren Wünschen. Abschließend können Sie den Backup-Job durch drücken von "'''OK'''" erstellen.
Datei:Tape Backup PBS Inventory.png|Unter "'''Inventory'''" sollte der Status nun auf "'''Writable'''" stehen.
Datei:Tape Backup PBS Übersicht.png|Nach erfolgreicher Konfiguration, sollte Ihr System ähnlich zu dieser Grafik aussehen.
</gallery>Nachdem Sie alle Schritte durchgeführt haben, haben Sie Ihre Tape Library / Autoloader erfolgreich in den Proxmox Backup Server eingebunden.

'''Hinweis''': Testen Sie sicherheitshalber den Backup-Job, bevor Sie das System im Produktivbetrieb nutzen.

Autor: Niklas Pauli

Niklas Pauli arbeitet im Product Management Team von Thomas-Krenn. Er absolvierte am Gymnasium Freyung seine Allgemeine Hochschulreife und anschließend seine Ausbildung als Fachinformatiker für Systemintegration bei der Thomas-Krenn.AG. Nach seiner Ausbildung beschäftigt er sich weiterhin mit den Themengebieten Proxmox VE inkl. Ceph, Backup (Proxmox, Veeam, SEP) oder dem Thomas-Krenn-Wiki.

Autor: Paul Streifinger

Installation Virtual Tape Library

2026-01-28T14:52:56Z

Aranzinger:

Dieser Artikel beschreibt, wie Sie eine Virtual Tape Library installieren und konfigurieren. Eine Virtual Tape Library bietet verschiedene Vorteile gegenüber einer gewohnten Tape Library, wie beispielsweise die Möglichkeit die Tape-Backups in die Cloud auszulagern oder eine höhere Schreib- und Leseperformance aufgrund der emulierten Tapes.

Dieser Artikel zeigt die Installation und Konfiguration einer VTL anhand von QUADStor, sowie StarWind.

== Voraussetzungen: ==

=== QUADStor: ===

VM mit installierten Debian 12.X, es ist empfohlen auf dieser VM keine weiteren Dienste zu betreiben und diese lediglich als VTL zu nutzen
VM mit min. 8GB RAM (16GB wenn viel Traffic geplant ist, 64GB wenn Dedup eingesetzt werden sollte)
VM mit min. 4 Cores
Alternativ auch als Hardware-System möglich
gültige Subscription, QUADStor überarbeitet aktuell deren Lizenzmodell

=== StarWind: ===

VM mit installierten Windows oder Linux
min. 4 vCPU mit 1.7GHz (VM), min. 8 vCPU mit 1,7GHz (VM + ZFS), min. 1 CPU mit 1.7GHz (Bare-Metal)
min 8GB RAM; min. 16GB RAM bei ZFS
seperater Datenträger oder Partition für VTL; Kapazität je nach Nutzung
Alternativ auch als Hardware-System möglich

== VTL mit QUADStor ==

=== Installation QUADStor VTL ===
Zu Beginn müssen einige Pakete nachinstalliert werden, welche für den Betrieb der QUADStor VTL benötigt werden:<pre>
apt update

apt install uuid-runtime build-essential sg3-utils apache2 gzip xz-utils postgresql libpq-dev psmisc linux-headers-`uname -r`

a2enmod cgi
</pre>Anschließend muss der Webserver gestartet werden:<pre>
systemctl restart apache2
</pre>

Nun muss zusätzlich das Installationspaket für QUADStor auf den Server geladen werden, gehen Sie dazu auf die offizielle QUADStor Website und suchen Sie die passende Version, je nach OS und Version.

In diesem Beispiel wird auf das Paket für Debian 12.X zurückgegriffen, das ausgewählte Paket können Sie nun mit wget auf die VM laden und anschließend installieren:<pre>
wget https://www.quadstor.com/vtldownloads/quadstor-vtl-ext-3.0.79.21-debian12-x86_64.deb
apt install ./quadstor-vtl-ext-3.0.79.21-debian12-x86_64.deb
</pre>
Um den Dienst zu aktivieren führen Sie folgenden Befehl aus:<pre>
systemctl enable --now quadstorvtl.service

</pre>
Zum Schluss kann der Dienst überprüft werden, ob dieser aktiviert und funktionsfähig ist, falls dies der Fall ist muss die VM einmal neugestartet werden:<pre>
root@np-vtl-01:~# systemctl status quadstorvtl.service
● quadstorvtl.service - QUADStor Virtual Tape Library

    Loaded: loaded (/lib/systemd/system/quadstorvtl.service; enabled; preset: enabled)

    Active: active (running) since Wed 2024-08-21 08:43:28 CEST; 34min ago

     Tasks: 1724

    Memory: 241.4M

       CPU: 4.031s

    CGroup: /system.slice/quadstorvtl.service

            ├─637 /quadstorvtl/sbin/coredev

            ├─660 /quadstorvtl/sbin/ietd

            └─663 /quadstorvtl/sbin/vtmdaemon

Aug 21 08:43:28 np-vtl-01 vtmdaemon[663]: tl_server_load_conf:3933 ioctl qload
Aug 21 08:43:28 np-vtl-01 vtmdaemon[663]: tl_server_load_conf:3939 restart export jobs
Aug 21 08:43:28 np-vtl-01 vtmdaemon[663]: tl_server_load_conf:3942 reply to client
Aug 21 08:43:28 np-vtl-01 vtmdaemon[663]: tl_server_restart_export_jobs:6641 start
Aug 21 08:43:28 np-vtl-01 vtmdaemon[663]: tl_server_load_conf:3944 end
Aug 21 08:43:28 np-vtl-01 vtmdaemon[663]: tl_server_restart_export_jobs:6704 end
Aug 21 08:43:28 np-vtl-01 systemd[1]: Started quadstorvtl.service - QUADStor Virtual Tape Library.

root@np-vtl-01:~# reboot
</pre>

Nun können Sie sich auf die Weboberfläche von QUADStor mit der IP Ihrer VM verbinden <code><nowiki>http://your.server.ip/</nowiki></code>

=== Konfiguration QUADStor VTL ===
Hinweis: Für die Definition der Changer und Drives können Sie auch Import-Files von QUADStor nutzen. Diese finden Sie hier: Definition Files<gallery>
Datei:Webinterface QUADStor.png|Hier sehen Sie das Webinterface von QUADStor. Um die Konfiguration zu beginnen klicken Sie auf '''[Physical Storage]'''.
Datei:QUADStor Physical Storage.png|Hier können die nicht zugewiesen Disks den jeweiligen Storage-Pool zugewiesen durch klicken auf '''[Add]'''. Führen Sie dies für alle Disks durch.
Datei:QUADStor Physical Storage Add.png|Wählen Sie hier den Default Pool aus und klicken Sie '''[Submit]'''. Die Zuordnung sollte anschließend in der Übersicht zu sehen sein.
Datei:QUADStor Add Storage Pool.png|Falls Sie nicht den Default Pool benutzen möchten, können Sie einen neuen Pool unter '''[Storage Pools]''' erstellen. Alternativ dazu können Sie in diesen Reiter auch den Default Pool nach Ihren Wünschen anpassen. Klicken Sie dazu auf '''[View]'''.
Datei:QUADStor Add Drive Definition.png|Nun müssen unter '''[Device Definitions]''' die '''[Drive Definition]''' angepasst werden, klicken Sie dazu auf '''[Add Drive Definition]''' und passen Sie die Parameter an. Eine Erklärung der Parameter ist in der untenstehenden Tabelle zu finden. Klicken Sie dann auf '''[Submit]'''.
Datei:QUADStor Add Changer Definition.png|Unter dem gleichen Reiter müssen auch die Changer erstellt werden, klicken Sie dazu auf '''[Add Changer Definitions]''' und passen Sie die Werte an. Übernehmen Sie die Konfiguration durch Klicken auf '''[Submit]'''.
Datei:QUADStor Device Definition Summary.png|Anschließend sollten die Definitionen ähnlich hierzu aussehen.
Datei:QUADStor Virtual Libaries.png|Um nun das VTL zu erstellen gehen Sie auf '''[Virtual Libraries]''' und klicken Sie auf '''[Add VTL]'''. Anschließend können Sie einen Namen, VDrives, VSlots sowie die Definitions von vorhin vergeben. Eine Erklärung dazu finden Sie weiter unten.
Datei:QUADStor Virtual Libaries Summary.png|Die Konfiguration sollte ähnlich hierzu aussehen. Um die Konfiguration abzuschließen gehen Sie auf '''[Add VCartridge]'''.
Datei:QUADStor Add VCartidgePNG.png|Hierbei können Sie unter '''[Number of VCartridge]''' definieren, wie viele Tapes in die VSlots integriert werden sollten. Zusätzlich muss auch noch ein Label/Prefix vergeben werden, dieser muss zwingend aus 6 Zeichen, sowie einer 0, für die automatische Nummerierung, bestehen
</gallery>

Begriffserklärung Changer Definitions:


Begriff	Erklärung
Name	Einzigartiger Name für die Changer Definition. Kann nur Zahlen und Buchstaben enthalten.
Vendor	Nachgebildeter Herstellername. Kann nur Zahlen und Buchstaben enthalten.
Product	Nachgebildeter Produktname. Kann Zahlen, Buchstaben sowie Leerzeichen enthalten.
Revision	Nachgebildeter Firmware-Stand. Kann Zahlen, Buchstaben, Leerzeichen und Punkte enthalten.
Serial Prefix	Präfix für die automatisch generierte Seriennummer. Wird vor die Seriennummer gestellt.
Serial Suffix	Suffix für die automatisch generierte Seriennummer. Wird an die Seriennummer angestellt.
Serial Length	Länge der automatisch generierten Seriennummer (meist zwischen 10 - 12)
Inquiry Length	Länge der SCSI-Abfrageantwort (meist 56)
Drive Start Address	Gibt die Startadresse für Drives an (Kann Default gelassen werden)
IE Start Address	Gibt die IE Start-Adresse für Drives an (Kann Default gelassen werden)
Slot Start Address	Gibt die Slot Start-Adresse für Drives an (Kann Default gelassen wereden)
AVoltag	Legt fest ob der Changer seine virt. Laufwerksseriennummer als Antwort auf ein SCSI Read Element meldet oder nicht.

Begriffserklärung Drive Definitons:

Begriff	Erklärung
Name	Einzigartiger Name für die Drive Definition. Kann nur Zahlen und Buchstaben enthalten.
Vendor	Nachgebildeter Herstellername. Kann nur Zahlend und Buchstaben enthalten.
Product	Nachgebildeter Produktname. Kann Zahlen, Buchstaben und Leerzeichen enthalten.
Revision	Nachgebildeter Firmware-Stand. Kann Zahlen, Buchstaben, Leerzeichen und Punkte enthalten.
Serial Suffix	Suffix für die automatisch generierte Seriennummer. Wird an die Seriennummer angestellt.
Serial Prefix	Prefix für die automatisch generierte Seriennummer. Wird vor die Seriennummer gestellt.
Serial Length	Länge der automatisch generierten Seriennummer (meist zwischen 10 -12)
Inquiry Length	Länge der SCSI-Abfrageantwort (meist 56)
Media Type	Definiert welcher Typ an Tape emuliert wird, wie LTO8, LTO7, etc.

== VTL mit StarWind ==

=== Installation StarWind ===
Diese Installation wird auf einem Windows Server 2022. Um die Installation zu beginnen, führen Sie die heruntergeladene EXE-Datei aus.

'''Hinweis:''' Zum Testen von StarWind VTL brauchen Sie einen Lizenz-Key für die Trail-Variante mit der Free-Version haben Sie nur einen sehr eingeschränkten Funktionsumfang<gallery>
Datei:StarWind vSAN.png|Zu Beginn sehen Sie die Installationsnotizen.
Datei:StarWind vSAN Installation path.png|Wählen Sie hier den Installationspfad aus.
Datei:StarWind vSAN VTL Checkbox.png|Haken Sie hierbei alle benötigten Pakete an. Alternativ können Sie auch ['''Full'''] auswählen, damit alle Abhängigkeiten berücksichtigt werden.
Datei:StarWind vSAN Start Menu.png|Geben Sie nun einen Pfad für das Start Menü ein.
Datei:StarWind vSAN Desktop Icon.png|Gegebenenfalls können Sie in diesem Schritt ein Desktop Icon erstellen lassen.
Datei:StarWind vSAN Licence Key.png|Anschließend müssen Sie angeben, ob Sie bereits einen Licence-Key haben oder nicht. Falls nicht öffnet sich die StarWind Webseite und Sie können einen Key beantragen.
Datei:StarWind vSAN Add Licence Key.png|Folgend muss der Pfad zum Licence-Key eingegeben werden.
Datei:StarWind vSAN Summary.png|Nun sehen Sie eine kurze Summary über die Lizenz.
Datei:StarWind vSAN EULA.png|Anschließend müssen Sie die EULA akzeptieren.
Datei:StarWind vSAN Summary2.png|Nun sehen Sie eine Übersicht über die konfigurierten Parameter, falls diese Ihren Wünschen entsprechen, klicken Sie auf '''[Install]'''.
Datei:StarWind vSAN Basic Config.png|Folgend können Sie noch verschiedene Parameter wie Ports oder Passwörter anpassen. Durch Klicken auf '''[OK]''' wird die Installation abgeschlossen.
</gallery>
=== Konfiguration StarWind ===
Nach der erfolgreichen Installation müssen noch ein paar Konfigurationen durchgeführt werden, damit Sie die VTL in ihr System einbinden können:<gallery>
Datei:StarWind Add Storage.png|Nun können Sie die StarWind Management Console öffnen, Ihnen wird hierbei zu Beginn angezeigt, dass noch kein Pool konfiguriert ist.
Datei:StarWind Select Drive2.png|Gehen Sie um diesen zu konfigurieren auf der linken Seite unter ['''Server'''] auf Ihren Server und klicken Sie auf ['''Connect'''], anschließend können Sie das jeweilige Laufwerk für den Pool auswählen.
Datei:StarWind Add VTL.png|Anschließend klicken Sie auf '''"Add VTL Device"'''. Hier können Sie eine neue VTL erstellen oder eine bereits existierende hinzufügen. Geben Sie dazu den jeweiligen Pfad an.
Datei:StarWind Select Devices.png|Wählen Sie zusätzlich ein Model aus, welches emuliert werden sollte und klicken Sie auf ['''Next'''].
Datei:StarWind VTL Target.png|Nun können Sie einen Alias für das VTL Target angeben. Geben Sie dazu einen Namen an und wählen Sie ['''Create new Target'''] aus. Zusätzlich können Sie auch die Verbindung von mehreren iSCSI Endpunkten zulassen. Klicken Sie folgend auf ['''Next'''].
Datei:StarWind Creation Page.png|Die VTL wird nun erstellt und konfiguriert
Datei:StarWind Final.png|Zuletzt sehen Sie noch einmal den Targetnamen, mit welchen Sie die VTL an Ihr System anbinden können. Klicken Sie zum Abschluss auf ['''Close'''].
</gallery>Anschließend können Sie Ihre jeweilige VTL in Ihre Backupinfrastruktur anbinden und mit der Sicherung beginnen.
==Weitere Informationen==
Installing a Virtual Tape Library 
Installation on RHEL CentOS SLES Debian

Autor: Niklas Pauli

Apache2

2026-01-28T12:36:19Z

Aranzinger:

Der '''Apache HTTP Server''' (unter Linux-Systemen meist als '''Apache2''' bezeichnet) ist einer der weltweit am häufigsten eingesetzten Webserver.<ref>https://httpd.apache.org/</ref>

Er wird von der '''Apache Software Foundation''' entwickelt und ist freie Open-Source-Software.<ref>https://www.apache.org/foundation/</ref>

Apache2 gilt als stabil, flexibel und leistungsfähig und bildet seit vielen Jahren die Basis zahlreicher Webanwendungen und Internetdienste.
== Was ist Apache2? ==

Apache2 ist ein '''Webserver''', der HTTP- und HTTPS-Anfragen von Clients entgegennimmt und daraufhin Webseiten oder Webanwendungen ausliefert.

Er unterstützt sowohl statische Inhalte wie HTML, CSS oder Bilder als auch dynamische Inhalte, die über Skriptsprachen oder Backend-Dienste erzeugt werden.

Ein wesentliches Merkmal von Apache2 ist sein '''modularer Aufbau'''. Funktionen werden über Module bereitgestellt, die je nach Bedarf aktiviert oder deaktiviert werden können.<ref>https://httpd.apache.org/docs/2.4/mod/</ref>

== Zentrale Eigenschaften ==

Open Source und kostenfrei nutzbar<ref>https://www.apache.org/licenses/</ref>
Modularer Aufbau
Hohe Stabilität und Sicherheit
Große Community und umfangreiche Dokumentation
Plattformübergreifend (Linux, Windows, Unix)

== Typische Einsatzmöglichkeiten ==

=== Hosting von Webseiten ===

Apache2 wird häufig zum Betrieb klassischer Webseiten eingesetzt, darunter:

Unternehmenswebseiten
Blogs
Foren
Wikis
Dokumentationsportale

Dank Virtual Hosts können mehrere Webseiten parallel auf einem Server betrieben werden.<ref>https://wiki.ubuntuusers.de/Apache/Virtual_Hosts/</ref>

=== Betrieb dynamischer Webanwendungen ===

Apache2 wird oft in Kombination mit Skript- und Programmiersprachen genutzt, zum Beispiel:

'''PHP''' (z. B. WordPress, Joomla, MediaWiki)<ref>https://www.php.net/manual/en/install.apache2.php</ref>
'''Python''' (z. B. über mod_wsgi)<ref>https://modwsgi.readthedocs.io/</ref>
'''Perl''' (z. B. über mod_perl)<ref>https://perl.apache.org/</ref>

Ein klassisches Beispiel ist der sogenannte '''LAMP-Stack''' (Linux, Apache, MySQL/MariaDB, PHP/Perl/Python).<ref>https://wiki.ubuntuusers.de/LAMP/</ref>

== Wichtige Module ==

Apache2 stellt zahlreiche Module bereit, darunter:

'''mod_ssl''' – Unterstützung für HTTPS<ref>https://httpd.apache.org/docs/2.4/mod/mod_ssl.html</ref>
'''mod_rewrite''' – URL-Umschreibungen<ref>https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html</ref>
'''mod_headers''' – Steuerung von HTTP-Headern<ref>https://httpd.apache.org/docs/2.4/mod/mod_headers.html</ref>
'''mod_proxy''' – Proxy- und Reverse-Proxy-Funktionen
'''mod_auth''' – Authentifizierung und Zugriffskontrolle<ref>https://httpd.apache.org/docs/2.4/howto/auth.html</ref>

== Sicherheit ==

Apache2 gilt als sicher, sofern er korrekt konfiguriert und regelmäßig aktualisiert wird.<ref>https://httpd.apache.org/security/</ref>

Typische Sicherheitsmaßnahmen umfassen:

Einsatz von HTTPS (TLS/SSL)
Regelmäßige Sicherheitsupdates
Einschränkung von Dateirechten
Nutzung von Security-Headern
Deaktivieren nicht benötigter Module

== Fazit ==

Apache2 ist ein bewährter, leistungsfähiger und äußerst vielseitiger Webserver.

Durch seinen modularen Aufbau eignet er sich sowohl für kleine private Webseiten als auch für komplexe Unternehmenslösungen.

Die große Community, die umfangreiche Dokumentation und die kontinuierliche Weiterentwicklung machen Apache2 auch heute zu einer tragenden Säule moderner Webinfrastrukturen.

== Weitere Informationen ==
Eine Installationsanleitung für '''Apache2''' finden sie hier:
Apache2 - Installation

== Quellen ==
<references />

Autor: Adrian Zillner

Adrian Zillner ist im Technical Service bei der Thomas-Krenn AG tätig. Er ist für das Betreuen von Kunden und Beantworten von Fragen bei technischen Problemen zuständig.

Apache2 - Installation

2026-01-28T12:34:31Z

Aranzinger:

Dieser Artikel beschreibt, wie Sie unter Ubuntu 24.04 LTS einen Apache2 Webserver installieren und eine einfache Website bereitstellen.
== Voraussetzungen ==

Ubuntu 24.04 LTS (Server oder Desktop)
Sudo- oder Root-Zugriff
Internetverbindung

Die Installation erfolgt ausschließlich aus den offiziellen Ubuntu-Paketquellen.

== Installation von Apache2 ==

Die Installation wird direkt über den Paketmanager von Ubuntu durchgeführt.

<gallery>
Apache2_Installation-01.png | '''Schritt 1:''' Zuerst sollten die Paketlisten aktualisiert und vorhandene Pakete auf den neuesten Stand gebracht werden: <code>sudo apt update && sudo apt upgrade -y</code>
Apache2_Installation-02.png | '''Schritt 2:''' Anschließend kann der Apache2 Webserver installiert werden: <code>sudo apt install apache2 -y</code>
Apache2_Installation-03.png | '''Schritt 3:''' Mit folgendem Befehl kann geprüft werden, ob der Apache2-Dienst aktiv ist: <code>systemctl status apache2</code>
Apache2_Installation-04.png | '''Schritt 4:''' Ist der Dienst aktiv, sollte der Webserver nun im Browser unter <code>http://IP-Adresse/</code> erreichbar sein.
</gallery>

== Eigene Website einfügen ==

Nach der erfolgreichen Installation kann der Standardinhalt durch eine eigene Website ersetzt werden.

<gallery>
Apache2_Installation-05.png | '''Schritt 1:''' Wechseln Sie in das Standard-Webverzeichnis von Apache: <code>cd /var/www/html/</code>
Apache2_Installation-06.png | '''Schritt 2:''' Optional können Sie die bestehende <code>index.html</code> sichern oder entfernen.
Apache2_Installation-07.png | '''Schritt 3:''' Erstellen Sie eine neue Beispiel-Webseite: <code>sudo nano index.html</code>
Apache2_Installation-08.png | '''Schritt 4:''' Nach dem Speichern der Datei ist die neue Website sofort im Browser sichtbar.
</gallery>

== Fehlerbehebung ==

'''Webseite nicht erreichbar'''
- Prüfen, ob der Dienst läuft: <code>systemctl status apache2</code>
- Firewall-Regeln kontrollieren: <code>sudo ufw status</code>

'''Änderungen werden nicht angezeigt'''
- Browser-Cache leeren oder Seite neu laden (<code>Strg + F5</code>)
- Dateirechte prüfen: <code>ls -l /var/www/html</code>

'''Port 80 belegt'''
- Belegte Ports prüfen: <code>sudo ss -tulpn</code>

== Zusammenfassung ==

Mit wenigen Schritten lässt sich unter Ubuntu 24.04 LTS ein Apache2 Webserver installieren und betreiben.
Nach der Installation kann der Standardinhalt einfach durch eigene Webseiten ersetzt und der Webserver mit grundlegenden Maßnahmen abgesichert werden.

Autor: Adrian Zillner

Adrian Zillner ist im Technical Service bei der Thomas-Krenn AG tätig. Er ist für das Betreuen von Kunden und Beantworten von Fragen bei technischen Problemen zuständig.

Sicherheitshinweise zu AMD-SB-3027

2026-01-22T09:20:56Z

Aranzinger:

Am '''15. Januar 2026''' wurde von AMD das Security Bulletin AMD-SB-3027 <ref>SEV-SNP Guest Stack Pointer Corruption Vulnerability (www.amd.com/en/resources/product-security)</ref> veröffentlicht. AMD geht davon aus, dass diese Sicherheitslücke auf unzureichende Zugriffskontrollen zurückzuführen ist, die den Hypervisor daran hindern, ein internes Konfigurationsbit zu setzen.

Dieser Angriff könnte es einem böswilligen Hypervisor ermöglichen, die Konfiguration der CPU-Pipeline zu manipulieren, was möglicherweise zu einer Beschädigung des Stack-Pointers innerhalb eines SEV-SNP-Gasts führen könnte, der auf dem Sibling SMT-Thread (Simultaneous Multithreading) ausgeführt wird.

AMD hat Abhilfemaßnahmen für diese Sicherheitslücke veröffentlicht.

== Betroffene Systeme ==

Hier eine tabellarische Aufstellung der betroffenen Prozessoren.


Program	Former Code Name	Mitigation Option 1: µcode Option 2: AGESA/PI	SEV Mitigation Vector Bit	CVE
AMD EPYC™ 7002 Series Processors	"Rome"	Not Affected	CVE-2025-29943
AMD EPYC™ 7003 Series Processors	“Milan”	0x0A0011DB	Milan B1:0x0A0011DE Milan-X:0x0A001247 OR MilanPI 1.0.0.H	µcode standalone release: 2025-07-14 AGESA Release 2025-09-04
AMD EPYC™ 7003 Series Processors	"Milan-X"	0x0A001244
AMD EPYC™ 9004 Series Processors	"Genoa"/	0x0A101154	Genoa:0x0A101156 Genoa-X: 0x0A101251 Bergamo/Sienna A2: 0x0AA0021B OR GenoaPI 1.0.0.H	µcode standalone release: 2025-07-14 AGESA Release 2025-12-15
"Genoa-X"	0x0A10124F
"Bergamo"	0x0AA00219
AMD EPYC™ 9005 Series Processors	"Turin Classic"	0x0B00211E	Turin C1: 0x0B002151 Turin Dense B0: 0x0B10104E OR TurinPI 1.0.0.6	µcode standalone release: 2025-07-14 AGESA Release: 2025-06-30
“Turin Dense”	0x0B101028

Nachfolgend ein Auszug aus dieser Tabelle, in der alle Supermicro Mainboards enthalten sind, die von Thomas Krenn angeboten werden: <ref>AMD Security Bulletin AMD-SB-3027, Januar 2027 (www.supermicro.com)</ref>


AMD Motherboard	'''BIOS Version'''
H12SSW-iN/NT	3.5
H12SSL-i/C/CT/NT	3.5
H12DSi-N6/NT6	3.5
H13SSW	3.7
H13SSL-N/NT	3.7

=== Updates für Produkte von Thomas-Krenn ===
Updates zum jeweiligen System finden Sie im <tklink type="sitex" id="440">Downloadbereich von Thomas-Krenn</tklink>.
Die Updates im Downloadbereich wurden von uns getestet, um die Stabilität und Kompatibilität unserer Systeme zu gewährleisten.

Falls Sie die aktuellste Version für ihr System benötigen und diese noch nicht bei uns im Downloadbereich zu finden ist, können Sie diese im Downloadbereich bei Asus, Supermicro oder Gigabyte beziehen.

== Einzelnachweise ==
<references/>

== Weitere Informationen ==

AMD Security Bulletin AMD-SB-3027 (supermicro.com, Januar 2026)

Autor: Thomas-Krenn.AG

NVMe I/O Error Fehlermeldung unter Linux analysieren

2026-01-21T14:19:29Z

Aranzinger:

Kommt es auf einem Linux System zu NMVe I/O Error Situationen, protokolliert der Kernel Fehlerinformationen welche mittels '''dmesg''' Kommando abgefragt werden können. In diesem Artikel zeigen wir, wie Sie eine '''NVMe I/O Error Fehlermeldung analysieren'''.

== Beispielfehler I/O Error sct 0x0 sc 0x4 DNR ==

Completion Queue Entry Status Field: In Figure 100 der NVM Express® Base Specification Revision 2.3<ref name=nvme-base-23>NVM Express® Base Specification Revision 2.3 (nvmexpress.org)</ref> wird die Bedeutung der Bits Do Not Retry ('''DNR'''), More ('''M'''), Command Retry Delay ('''CRD'''), Status Code Type ('''SCT''') und Status Code ('''SC''') erklärt.

Auf einem Testsystem mit Linux-Kernel 6.8.0-55-generic #57-Ubuntu kommt es im Zuge von I/O Tests mit fio zu einem Abbruch des fio-Tests durch einen I/O Error. In der '''dmesg''' Ausgabe ist zu sehen:

Die erste Zeile enthält folgende Informationen:

<code>[74942.261934] nvme0c0n1: I/O Cmd(0x1) @ LBA 218630656, 256 blocks, I/O Error (sct 0x0 / sc 0x4) DNR</code>

<code>[74942.262623] I/O error, dev nvme0c0n1, sector 218630656 op 0x1:(WRITE) flags 0x2008800 phys_seg 17 prio class 0</code>

Speziell interessant sind dabei folgende Teile der Meldung:

I/O Error
sct 0x0
sc 0x4
DNR

Die Bedeutung dieser Werte sind in der NVMe Express Base Specification<ref>NVM Express® Base Specification (nvmexpress.org)</ref> dokumentiert. In Kapitel 4.2.3 (Status Field Definition) der NVM Express® Base Specification Revision 2.3<ref name=nvme-base-23 /> werden die einzelnen Elemente des Status Field folgendermaßen beschrieben:

'''SCT''' (3 bits) - '''Status Code Type''' - Gibt den Typ des Statuscodes an, den der Controller (der NVMe SSD) zurückgibt.
'''SC''' (8 bits) - '''Status Code''' - (Details siehe weiter unten.)
'''CRD''' (2 bits) - '''Command Retry Delay''' - Wenn das DNR-Bit im Statusfeld auf „1“ gesetzt ist, ist dieses Feld reserviert. (Weitere Details siehe NVM Express Base Specification.)
'''M''' (1 bit) - '''More''' - Wenn dieses Bit auf „1“ gesetzt ist, gibt es weitere Statusinformationen zu diesem Befehl als Teil der Seite „Error Information log page“, die mit dem Befehl „Get Log Page“ abgerufen werden können. Wenn dieses Bit auf „0“ gesetzt ist, gibt es keine zusätzlichen Statusinformationen zu diesem Befehl.
'''DNR''' (1 bit) - '''Do Not Retry''' - Wenn dieses Bit auf „1“ gesetzt ist, bedeutet dies, dass derselbe Befehl, wenn er erneut an einen Controller im NVM-Subsystem gesendet wird, voraussichtlich fehlschlagen wird. Wenn dieses Bit auf „0“ gesetzt ist, bedeutet dies, dass derselbe Befehl bei einer Wiederholung erfolgreich sein kann.

=== Status Code Type ===

In Figure 101 werden die vier Status Code Types Generic Command Status, Command Specific Status, Media and Data Integrity Errors und Path Related Status erklärt.

Die NVM Express Base Specification definiert mehrere Status Code Types:


Status Code Type (sct)	Definition
'''0'''	'''Generic Command Status'''
1	Command Specific Status
2	Media and Data Integrity Errors
3	Path Related Status
4, 5, 6	reserviert
7	Hersteller-spezifisch

Im Beispiel oben (''I/O Error (sct 0x0 / sc 0x4) DNR'') lautet der Status Code Type 0 (''sct 0x0'').

=== Status Code ===
Abhänging vom jeweiligen Status Code Type, hat der zusätzlich mit übermittelte Status Code eine unterschiedliche Bedeutung.

==== Status Code (Generic Command Status) ====

Figure 102: Status Code Bedeutungen von Generic Command Status Informationen. Im Beispiel lautet der Status Code ''sc 0x4'', das bedeutet '''Data Transfer Error'''.

Die Bedeutung des Status Codes bei einem Generic Command Status (sct = 0) ist in Kapitel 4.2.3.1 definiert. Hier dazu ein Auszug:


Status Code	Definition
0	Successful Completion: Der Befehl wurde ohne Fehler ausgeführt.
1	Invalid Command Opcode: Ein reservierter codierter Wert oder ein nicht unterstützter Wert im Befehls-Opcode-Feld.
2	Invalid Field in Command: Ein reservierter codierter Wert oder ein nicht unterstützter Wert in einem definierten Feld (außer dem Opcode-Feld).
3	Command ID Conflict: Die Befehlskennung (Command ID) wird bereits verwendet. Hinweis: Wie viele Befehle nach einem Konflikt durchsucht werden, hängt von der jeweiligen Implementierung ab.
'''4'''	'''Data Transfer Error''': Beim Übertragen der mit einem Befehl verbundenen Daten oder Metadaten ist ein Fehler aufgetreten.
...

Im Beispiel oben (''I/O Error (sct 0x0 / sc 0x4) DNR'') lautet der Status Code 4 (''sc 0x4''). Es handelt sich damit um einen '''Data Transfer Error'''.

==== Status Code (Command Specific Status) ====
Die Bedeutung des Status Codes bei einem Command Specific Status (sct = 1) ist in Kapitel 4.2.3.2 definiert. In diesem Beispiel gehen wir nicht näher darauf ein.

== Interpretation der Statusinformation ==
Die Statusinformation "'''Data Transfer Error'''" deutet auf Probleme bei der Datenübertragung hin. Potentiell können beispielsweise Kabel, Steckverbindungen oder Backplane die Ursache sein.

Die Detail-Ausgabe von lspci zeigt, dass die betroffene NVMe SSD via PCIe 5.0 (32GT/s) angebunden ist:
<pre>

lspci -s 81:00.0 -vvv

81:00.0 Non-Volatile memory controller: KIOXIA Corporation Device 0013 (rev 01) (prog-if 02 [NVM Express])

       Subsystem: KIOXIA Corporation Device 0045

       Physical Slot: 1

       [...]

       Capabilities: [70] Express (v2) Endpoint, MSI 00

               [...]

               LnkCap: Port #0, Speed 32GT/s, Width x4, ASPM not supported

                       ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+

               LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+

                       ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

               LnkSta: Speed 32GT/s, Width x4

                       TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

               [...]

               LnkCap2: Supported Link Speeds: 2.5-32GT/s, Crosslink- Retimer+ 2Retimers+ DRS-

               LnkCtl2: Target Link Speed: 32GT/s, EnterCompliance- SpeedDis-

                        Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-

                        Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot

</pre>

In diesem Beispiel kommt jedoch eine Backplane mit Oculink Buchse zum Einsatz. Oculink unterstützt laut Spezifikation PCIe 4.0, jedoch nicht PCIe 5.0.

Um die Verbindung auf PCIe 4.0 Geschwindigkeit (16GT/s) zu limitieren, kann man entweder das Tool setpci direkt mit den entsprechenden Parametern verwenden, oder das Skript pci_set_speed.sh von Alex Forenchich nutzen:<ref name=pcispeed>PCIe Set Speed (alexforencich.com)</ref>
<pre>

./pci_set_speed.sh 0000:81:00.0 4

Link capabilities: 007b7845
Max link speed: 5
Link status: 7045
Current link speed: 5
Configuring 0000:80:01.1...
Original link control 2: 001e0005
Original link target speed: 5
New target link speed: 4
New link control 2: 001e0004
Triggering link retraining...
Original link control: 70450040
New link control: 70450060
Link status: 7044
Current link speed: 4
</pre>

Nach dem Ausführen des Skriptes ist die PCIe Link Geschwindigkeit reduziert ('''LnkSta: Speed 16GT/s (downgraded)'''):
<pre>
root@xfuel:~# lspci -s 81:00.0 -vvv
81:00.0 Non-Volatile memory controller: KIOXIA Corporation Device 0013 (rev 01) (prog-if 02 [NVM Express])

       Subsystem: KIOXIA Corporation Device 0045

       Physical Slot: 1

       [...]

       Capabilities: [70] Express (v2) Endpoint, MSI 00

               [...]

               LnkCap: Port #0, Speed 32GT/s, Width x4, ASPM not supported

                       ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+

               LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+

                       ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

               LnkSta: Speed 16GT/s (downgraded), Width x4

                       TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

               [...]

               LnkCap2: Supported Link Speeds: 2.5-32GT/s, Crosslink- Retimer+ 2Retimers+ DRS-

               LnkCtl2: Target Link Speed: 32GT/s, EnterCompliance- SpeedDis-

                        Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-

                        Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot

</pre>

Folgende Tests mit fio zeigten keine Probleme mehr. Die Ursache für die '''Data Transfer Error''' war also die höhere (32GT/s) Übertragungsgeschwindigkeit von PCIe 5.0 über Komponenten (Backplane), die nur bis PCIe 4.0 freigegeben sind.

=== Skript zum Limitieren der PCIe Übertragungsrate ===
Hier ist zur Information der vollständige Code des Bash-Scripts von Alex Forenchich (Lizenz: [https://creativecommons.org/licenses/by-sa/4.0/ CC-BY-SA 4.0):<ref name=pcispeed>
<pre>

   #!/bin/bash

    

   dev=$1

   speed=$2

    

   if [ -z "$dev" ]; then

       echo "Error: no device specified"

       exit 1

   fi

    

   if [ ! -e "/sys/bus/pci/devices/$dev" ]; then

       dev="0000:$dev"

   fi

    

   if [ ! -e "/sys/bus/pci/devices/$dev" ]; then

       echo "Error: device $dev not found"

       exit 1

   fi

    

   pciec=$(setpci -s $dev CAP_EXP+02.W)

   pt=$((("0x$pciec" & 0xF0) >> 4))

    

   port=$(basename $(dirname $(readlink "/sys/bus/pci/devices/$dev")))

    

   if (($pt == 0)) || (($pt == 1)) || (($pt == 5)); then

       dev=$port

   fi

    

   lc=$(setpci -s $dev CAP_EXP+0c.L)

   ls=$(setpci -s $dev CAP_EXP+12.W)

    

   max_speed=$(("0x$lc" & 0xF))

    

   echo "Link capabilities:" $lc

   echo "Max link speed:" $max_speed

   echo "Link status:" $ls

   echo "Current link speed:" $(("0x$ls" & 0xF))

    

   if [ -z "$speed" ]; then

       speed=$max_speed

   fi

    

   if (($speed > $max_speed)); then

       speed=$max_speed

   fi

    

   echo "Configuring $dev..."

    

   lc2=$(setpci -s $dev CAP_EXP+30.L)

    

   echo "Original link control 2:" $lc2

   echo "Original link target speed:" $(("0x$lc2" & 0xF))

    

   lc2n=$(printf "%08x" $((("0x$lc2" & 0xFFFFFFF0) | $speed)))

    

   echo "New target link speed:" $speed

   echo "New link control 2:" $lc2n

    

   setpci -s $dev CAP_EXP+30.L=$lc2n

    

   echo "Triggering link retraining..."

    

   lc=$(setpci -s $dev CAP_EXP+10.L)

    

   echo "Original link control:" $lc

    

   lcn=$(printf "%08x" $(("0x$lc" | 0x20)))

    

   echo "New link control:" $lcn

    

   setpci -s $dev CAP_EXP+10.L=$lcn

    

   sleep 0.1

    

   ls=$(setpci -s $dev CAP_EXP+12.W)

    

   echo "Link status:" $ls

   echo "Current link speed:" $(("0x$ls" & 0xF))

</pre>

== Weitere Informationen ==

H12SSL-NT - Work around missing PCIe Force Link Speed option (forums.servethehome.com, 15.01.2024)

== Einzelnachweise ==
<references />

Autor: Werner Fischer

Installation von XCP-ng

2026-01-20T07:39:05Z

Aranzinger:

XCP-ng eignet sich als '''Open Source Virtualisierungsplatform''' zum Virtualisieren von Linux, Windows und BSD Systemen. Der folgende Artikel zeigt die '''Installation von XCP-ng''' auf einem Host System.

== Installationsmedium erstellen ==
Die Installation von XCP-ng können Sie über einen USB-Stick vornehmen. Im folgenden werden die einzelnen Schritt

=== ISO Download ===
Für die Installation der XCP-ng Image Files haben Sie zwei Optionen.

==== XCP-ng GitHub Repository ====
Im Github Repository finden Sie immer die aktuellsten Images als ''Full Version'', ''Netinstall Version'' und ''Upgrade Only Version''.

Die Images befinden sich hinter folgendem Link:

https://github.com/xcp-ng/xcp/releases

==== Offizielle XCP-ng Website ====
Sie können die Images auch über die offizielle Seite von XCP-ng beziehen:

https://xcp-ng.org/#easy-to-install

=== USB Stick erstellen ===

'''Hinweis: Bei der Erstellung des Installationsmediums werden alle Daten auf dem Stick gelöscht. Stellen Sie sicher, dass sich auf dem Medium keine noch benötigten Dateien befinden.'''

Bei der Erstellung eines bootbaren USB Sticks bieten sich Ihnen mehrere Möglichkeiten.

==== Applikationsbasiert ====
Sie können einen bootfähigen USB-Stick mit einer Applikation wie Rufus oder Ventoy erstellen:

Bootfähigen USB-Stick mit Rufus erstellen (ersetzen Sie DOS durch XCP-ng)

Bootfähigen USB-Stick mit Ventoy erstellen

==== dd ====
Auf einem Linux-System können Sie den USB Stick mit dem Kommando <code>dd</code> erstellen. Beachten Sie, dass Sie <code>/dev/sdX</code> durch die korrekte Bezeichnung für ihren USB-Stick ersetzen müssen:<pre>dd if=xcp-ng-8.3.0-20250606.iso of=/dev/sdX bs=8M status=progress oflag=direct</pre>

== Installation ==
Im folgenden eine Schrittweise Anleitung für die Installation von XCP-ng mit dem erstellten Installationsmedium:<gallery>
Datei:XCP-ng USBStick.png|Stecken Sie den erstellten USB-Stick am Server an und schalten Sie diesen ein
Datei:Gotobios.png|Drücken sie '''[Entf]''' im ins BIOS des Servers zu gelangen.
Datei:Usb stick boot.png|Booten sie vom erstellten USB Stick.
Datei:Xcp-ng install grub screen.png|Wählen Sie i'''nstall'''
Datei:Xcp-ng install keymap screen.png|Hier die passende Keymap wählen. '''[qwertz] de'''
Datei:Xcp-ng install welcome screen.png|Hier mit '''[Ok]''' für neue Installation oder Upgrade bestätigen.
Datei:Xcp-ng install EUA screen.png|Hier mit '''[Accept EUA]''' die license terms bestätigen.
Datei:Xcp-ng install OS storage screen.png|'''Ziellaufwerk''' für das Hostsystem auswählen
Datei:Xcp-ng install VM storage screen.png|VM Storage für virtuellen Maschinen auswählen
Datei:Xcp-ng install vms storage ext screen.png|Virtual Machine Storage Type auswählen. Hier in diesem Fall ['''<nowiki>EXT]</nowiki>'''
Datei:Xcp-ng install from local media screen.png|Installationquellentyp '''[Local Media]''' wählen
Datei:Xcp-ng install verfify media screen.png|'''[Verify installation source]''' das Quellmedium testen.
Datei:Xcp-ng install setpw screen.png|Hier das '''[Password]''' für den XCP-ng Host festlegen
Datei:Xcp-ng install config mgmt network screen.png|'''Management/Netzwerkinterface''' festlegen
Datei:Xcp-ng install IP-Networking screen.png|Hier den Addressierungstyp festlegen. Hier im Beispiel '''[IPv4]'''
Datei:Xcp-ng install IP-NetworkingConfig screen.png|alternativtext=Networking / Management hier im Beispiel : [DHCP] * für prod. Installationen sind fixed IPs empfehlenswert|Networking / Management hier im Beispiel: '''[DHCP]''' * für produktive Installationen sind fixe IPs empfehlenswert
Datei:Xcp-ng install sethostname.png|Hier den '''Hostnamen festlegen''', sowie die erreichbaren '''DNS''' Server
Datei:Xcp-ng install timezone screen.png|Die '''Zeitzone festlegen'''
Datei:Xcp-ng install timezone berlin screen.png|'''City/Area''' festlegen
Datei:Xcp-ng install NTP config screen.png|'''DHCP NTP''' Server für Zeitabgleich konfigurieren
Datei:Xcp-ng install confirm install screen.png|Jetzt die Installation mit '''[Install XCP-ng]''' starten
Datei:Xcp-ng during install screen.png|Nun wird XCP-ng auf dem Ziellaufwerk installiert
Datei:Xcp-ng install completed screen.png|Installation komplett durchgeführt, mit '''[OK]''' bestätigen. System wird neu gestartet.
</gallery>
== Erster Start ==
Nach der Installation wird auf der Konsole die URL angezeigt, über die Sie auf das XCP-ng Webinterface gelangen:
<gallery>
Datei:Xcp-ng install overview.png|Übersichtsseite der Settings auf dem lokalen Screen
Datei:XO-lite webinterface.png|Zugriff auf das XO-Lite Webinterface
Datei:XO-lite webinterface overview.png|Das Webinterface XO-LITE
</gallery>

Autor: Wilfried Seifert