Im ersten Teil der Serie über Proxmox Virtual Environment (Proxmox VE) ging es um die Installation und Grundkonfiguration von Proxmox selbst. Nun möchte man das System aber dazu einsetzen, wofür es gedacht ist: Zur Virtualisierung.
Der folgende Artikel beschreibt nun die Installation und Einrichtung eines Ubuntu Servers als virtuelle Maschine auf Proxmox.
Dazu wird Ubuntu Server 20.04 LTS genutzt. Die gezeigten Schritte sind aber auch auf andere Versionen des Ubuntu Servers oder gar auf andere Distributionen übertragbar.
Update-Historie (letztes Update: 23.04.2022)- 23.04.2022:
- Hinweise unter „Verzögerten Start beheben“ angepasst, da dies auch unter Ubuntu 22.04 LTS notwendig ist.
Inhalt
Vorbereitung: Herunterladen des ISO-Images von Ubuntu Server
Für die Installation auf einer virtuellen Maschine benötigen wir zunächst einmal ein ISO-Image des Betriebssystems. Dieses muss auf der Proxmox-Instanz zur Verfügung stehen.
Der einfachste Weg besteht darin, dass Proxmox sich die ISO-Datei von einer URL herunterlädt. Dazu öffnen wir den Knoten einer Proxmox-Instanz (hier „pve“) und klicken auf den Speicher local und hier im Menü auf ISO-Images. Hier kann man auch einen anderen Storage angeben, der zum Speichern von ISO-Images konfiguriert wurde.
Dies öffnet die Verwaltung der ISO-Images auf dem lokalen Speicher der Instanz. Wenn man hier schon das gewünschte ISO-Image auf dem Desktop-Rechner heruntergeladen hat, kann man diese Datei nun direkt über den Button Hochladen auf die Proxmox-Instanz uploaden.
Komfortabler ist aber meist der direkte Download: Dazu sucht man sich einfach einen Direkt-Link zum Download des ISO-Images heraus. Für Ubuntu Server ist dies z.B.: https://releases.ubuntu.com/20.04.3/ubuntu-20.04.3-live-server-amd64.iso
Anschließend kann man über den Button Von URL herunterladen in der ISO-Image-Verwaltung den Dialog zum Herunterladen öffnen. Hier gibt man dann die kopierte URL des ISO-Images an, klickt auf URL abfragen (damit Proxmox selbstständig den Dateinamen ermitteln kann) und startet den Download dann mit Herunterladen:
Es öffnet sich wieder ein Fenster mit dem Task Viewer, welches den Fortschritt des Downloads darstellt. Dieses Fenster kann geschlossen werden, der Download läuft weiterhin im Hintergrund – dies sieht man in der Oberfläche ganz unten: Alle laufenden (und abgeschlossenen) Tasks werden hier aufgeführt.
Nach einer kurzen Wartezeit sollte das ISO-Image erfolgreich herunter geladen worden sein.
Virtuelle Maschine erstellen
Nun kann auch schon die VM selbst erstellt werden. Dazu findet man in der Proxmox-Oberfläche oben rechts den Button Erstelle VM.
Es öffnet sich der Assistent zum Erstellen einer VM, den wir nun Schritt für Schritt durchgehen werden.
Beim Erstellen einer VM gibt es viele Optionen. Ich werde im Folgenden alle relevanten Einstellungen vorstellen und ggf. auch bestimmte Optionen empfehlen. Die zu wählenden Einstellungen hängen aber auch immer etwas vom geplanten Verwendungszweck der virtuellen Maschine ab. Im Zweifelsfall kann man im Assistenten auch immer auf den Button Hilfe klicken, wo viele Optionen nochmal detailliert beschrieben werden.
Im ersten Schritt werden allgemeine Informationen zur VM erfasst.
Hinweis: Es empfiehlt sich, die erweiterten Optionen zu aktivieren (roter Pfeil), damit man sämtliche Optionen des Assistenten nutzen kann.
Folgende Optionen sind hier relevant:
- Knoten: Hier wird die Proxmox-Instanz angegeben, auf der die VM erstellt werden soll. Nur relevant, wenn mehrere Knoten betrieben werden – in unserem Fall gibt es ja nur die Instanz „pve“.
- VM ID: Die ID der VM. Diese ID ist zunächst einmal frei wählbar. Ich vergebe hier meistens eine ID, die dem letzten Oktett der IP-Adresse entspricht, die die VM später zugewiesen bekommt. Soll die VM beispielsweise unter der IP 192.168.200.201 erreichbar sein, vergebe ich die ID 201. Hier kann man aber auch andere Strategien zu Vergabe der IDs nutzen, z.B. der Bereich von 100-199 für produktive Systeme, 200-299 für Test-Systeme, etc.
- Name: Der Name der VM, wie er später in der Proxmox-Oberfläche erscheinen soll.
- Beim Booten starten: Soll die VM beim Start des Proxmox-Systems automatisch mit gestartet werden, muss diese Option aktiviert werden.
- Die weiteren Optionen sind für den Augenblick nicht weiter relevant, da wir keinen Ressourcen-Pool haben und uns die Startreihenfolge der VMs erst einmal egal ist.
Nach einem Klick auf Vorwärts gelangt man zu den Einstellungen OS:
Hier wird das für die Installation benötigte ISO-Image angegeben, welches wir vorhin heruntergeladen haben. Die Angaben zum Gast Betriebssystem passen hier schon.
Beim nächsten Schritt wird das System näher konfiguriert:
- Grafikkarte: Hier wählt man die zu emulierende Grafikkarte. Die Standard-Einstellung sind in den meisten Fällen eine gute Wahl. In unserem Fall hat das Gast-OS keine grafische Oberfläche, daher ist diese Option nicht relevant.
- Maschinentyp: Hier kann der zu emulierende Chipsatz ausgewählt werden. Dies belässt man ebenfalls am besten auf den Standard-Einstellungen.
- Firmware: Diese Option regelt, ob ein (legacy) BIOS oder UEFI für die VM genutzt werden soll. Die Standard-Einstellung ist hier nach wie vor noch SeaBIOS, da die UEFI-Emulation lange Zeit noch Probleme bereitet hat. Da UEFI aber das modernere System ist und mittlerweile auch in Proxmox stabil läuft, sollte man hier OVMF (UEFI) wählen. Für ein UEFI-System bedarf es eine EFI-Partition, die hier gleich automatisch mit hinzugefügt wird.
- SCSI Controller: Definiert den emulierten Storage-Controller der VM. Seitens Proxmox wird hier VirtIO SCSI empfohlen, was auch die Standard-Einstellung ist.
- Qemu Agent: Mit aktivierter Option geht Proxmox davon aus, dass auf dem Gast-OS ein QEMU Agent installiert ist. Dies sind Gast-Erweiterungen, über die sich das Gast-OS besser steuern lässt (z.B. herunterfahren oder neustarten). Da Ubuntu erst einmal ohne diesen Agent installiert wird, sollte die Option an dieser Stelle deaktiviert bleiben, ansonsten wird Proxmox später versuchen, die VM über den QEMU Agent herunter zu fahren, was fehlschlagen wird. Die Integration mittels QEMU Agent wird später nach der VM-Installation nachgeholt.
- TPM hinzufügen: Der VM kann hier ein Trusted Platform Module hinzugefügt werden. Dies wird für die meisten Gäste nicht benötigt und kann daher deaktiviert bleiben.
Es folgt der Schritt, in dem die Festplatte des Gast-OS angelegt wird:
- Bus/Device: Dies belässt man am besten auf SCSI.
- Storage: Gibt den Speicherort der virtuellen Festplatte an. Da wir hier nur einen Storage für VM-Festplatten haben, kann hier nichts anderes ausgewählt werden. Wurden bei Proxmox weitere Storages hinzugefügt, die zum Speichern von virtuellen Festplatten genutzt werden können, sollte man hier den gewünschten Storage auswählen.
- Disk-Größe (GiB): Gibt die Größe der virtuellen Festplatte an. Welche Größe man hier wählt, hängt stark vom Verwendungszweck der VM ab. Zu beachten ist hier, dass dank LVM-Thin nicht sofort der gesamte Speicherplatz allokiert wird, sondern dass auf der (physischen) Festplatte des Proxmox-Hosts nur der Speicher in Anspruch genommen wird, den der Gast wirklich braucht.
- Cache: Gibt einen Caching-Algorithmus an. Dabei gibt es verschiedene Strategien, wie der Proxmox-Host dem Gast-OS mitteilt, dass Daten auf die virtuelle Festplatte geschrieben wurden. Die Standardeinstellung deaktiviert das Caching, d.h. dass das Gast-System über neu geschriebene Blöcke informiert wird, wenn diese tatsächlich auf dem physischen Medium gespeichert wurden. Mit den anderen Caching-Optionen kann die Sicherheit (z.B. bei einem Stromausfall ohne Verwendung einer BBU) oder aber die Performance erhöht werden. Die Standardeinstellung ist aber der beste Kompromiss zwischen Sicherheit und Performance und stellt daher einen guten Ausgangspunkt dar.
- Discard: Wenn das Gast-OS TRIM-Befehle unterstützt, sollte diese Option aktiviert werden. Dies macht v.a. Sinn, wenn die virtuelle Festplatte auf einer (physischen) SSD gespeichert ist.
- SSD Emulation: Wenn die virtuelle Festplatte auf einem SSD-Speicher liegt, sollte diese Option ebenfalls aktiviert werden.
- IO thread: Mit dieser Option nutzt Proxmox (oder besser gesagt QEMU) einen Thread pro Storage-Controller. Dies kann die Performance erhöhen, daher sollte diese Option aktiviert werden.
- Alle weiteren Optionen belässt man am besten auf den Standard-Werten.
Es folgen die Einstellungen bzgl. der CPU des Gast-Systems:
- Sockets bzw. Cores: Gibt die Anzahl der CPU-Sockets bzw. CPU-Cores für das virtuelle System an. Die Anzahl der Sockets sollte immer 1 betragen, es sein denn, das Mainboard des Host-System besitzt mehre CPU-Sockel (äußerst unüblich). Die Anzahl der CPU-Kerne kann man hier frei wählen, es sollten aber nicht mehr Kerne ausgewählt werden, als über die CPU des Host-Systems zur Verfügung stehen. Bei einem Quad-Core kann sollte man hier also maximal 4 wählen.
- Typ: Gibt den Typ der emulierten CPU an. Die Standardeinstellung (kvm64) ist ein CPU-Typ mit maximaler Kompatibilität, aber eingeschränktem Befehlssatz (basiert mehr oder weniger auf einem Pentium 4). Mit der Einstellung host wird genau die gleiche CPU emuliert, die das Host-System nutzt. Dies ist meist aus Performance-Gründen die beste Option.
- Alle anderen Optionen gehen hier sehr ins Detail uns sollten erst einmal auf den Standard-Einstellungen belassen werden.
Im nächsten Schritt wird der Speicher der virtuellen Maschine konfiguriert.
- Speicher (MiB): Gibt die Größe des Speichers (RAM) in MB an, die der VM zur Verfügung stehen soll.
- Min. Speicher (MiB): Wenn die VM nicht den gesamten Speicher nutzt, kann der Proxmox-Host den Speicher auf den hier angegebenen Wert reduzieren. Dieses Feature sorgt dafür, dass oftmals insgesamt weniger RAM auf dem Host für den Betrieb der VM benötigt und nur bei Bedarf der maximal zugewiesene Speicher zugewiesen wird. Damit diese Option genutzt werden kann, muss die Einstellung Balooning Gerät (s.u.) aktiviert werden.
- Balooning Gerät: Diese Option sorgt dafür, dass die virtuelle Maschine ihren genutzten Speicher im laufenden Betrieb ändern kann. Erst dadurch wird die dynamische Speicher-Allokation möglich. Daher sollte diese Option auf jeden Fall aktiviert werden.
Hinweis: Auch wenn diese Einstellung an dieser Stelle bereits aktiviert werden kann, wird auf dem Gastsystem der QEMU Agent benötigt, damit dieses Feature auch korrekt funktioniert. Ohne diesen Agent wird der VM immer der maximale Speicher zugewiesen.
Weiter geht es mit den Netzwerk-Einstellungen.
- Bridge: Dies ist die Netzwerk-Bridge, die für die Netzwerk-Kommunikation genutzt werden soll. Wenn der Proxmox-Host nur eine Netzwerkkarte hat, gibt es meist nur eine Bridge, welche hier standardmäßig ausgewählt wird.
- Modell: Das Modell der emulierten Netzwerkkarte. Aus Performance-Gründen belässt man dies auch am besten auf dem Standard VirtIO (paravirtualized).
- Alle weiteren Optionen sind eher für fortgeschrittene Netzwerk-Einstellungen und sollten auf den Standardwerten belassen werden.
Am Ende des Assistenten werden die Optionen der neuen virtuellen Maschine noch einmal zusammengefasst:
Mit einem Klick auf Abschließen wird die VM dann erstellt.
Übrigens sind die im Assistenten eingegebenen Informationen zu einer VM nicht in Stein gemeißelt, sondern können zu einem späteren Zeitpunkt noch geändert werden. Dies wird im weiteren Verlauf noch genauer erklärt.
Start der virtuellen Maschine und Installation des Gast-Betriebssystems
Nachdem die virtuelle Maschine nun in Proxmox angelegt wurde, kann diese nun gestartet werden.
Dazu wählen wir erst einmal die soeben erzeugte VM im linken Menü aus, klicken auf den Button Start und verbinden uns anschließend über die Weboberfläche mit der Maschine (Button Konsole).
Nun wird die VM vom konfigurierten ISO-Image gebootet und der Installer für Ubuntu Server wird angezeigt:
Da vermutlich schon jeder Leser dieses Blogs schon mal einen Ubuntu Server installiert hat, gehen ich nun nicht im Detail auf die Installation des Gast-Betriebssystems ein. Die Schritte zum Installieren unterscheiden sich hier nicht zu einer herkömmlichen Installation.
Nach erfolgter Installation kann übrigens die ISO-Datei des Ubuntu Servers wieder aus dem virtuelle DVD-Laufwerk entfernt werden, da diese nur für die Installation benötigt wurde. Hierzu markiert man einfach die virtuelle Maschine und klickt im Reiter Hardware doppelt auf das Laufwerk mit dem ISO-Image. Mit der Option Kein Medium verwenden wird das ISO-Image ausgeworfen.
Konfiguration von Ubuntu Server auf der virtuellen Maschine
Nach der Installation von Ubuntu Server sollte das Gast-Betriebssystem noch etwas angepasst werden, damit es optimal in der virtuellen Umgebung läuft. Dazu verbindet man sich einfach per SSH (oder der Browser-Konsole über Proxmox) auf die VM.
Updates
Zunächst einmal werden die obligatorischen Updates eingespielt:
apt update && apt upgrade -V && apt autoremove
Optimierung für die virtuelle Umgebung
Für den optimalen Betrieb sollte das Gast-OS „wissen“, dass es in einer virtuellen Umgebung läuft. Dies wird durch die Installation einiger Kernel-Module erledigt:
apt update apt install --install-recommends linux-virtual apt install linux-tools-virtual linux-cloud-tools-virtual
Ebenso sollte der I/O Scheduler so eingerichtet werden, dass der VM-Host die Optimierungen des I/O Scheduling vornimmt und nicht der Gast selbst. Dazu ändern wir im Gast-Betriebssystem die Konfiguration des Bootloaders:
nano /etc/default/grub
Folgende Zeile sollte hier enthalten sein:
GRUB_CMDLINE_LINUX_DEFAULT=""
Diese ändern wir ab zu:
GRUB_CMDLINE_LINUX_DEFAULT="elevator=noop"
Wenn Änderungen durchgeführt wurde, muss der Bootloader noch aktualisiert werden:
update-grub
Nach diesen Änderungen sollte man die VM einmal neu starten:
reboot now
Verzögerten Start beheben
Nach den Optimierungen für die virtuelle Umgebung kann man beobachten, dass der Start der VM deutlich länger dauert. Hier erscheint dann während des Boot-Vorgangs (den man über die Konsole nachverfolgen kann) folgende Meldung, was den Start um 90 Sekunden verzögert:
A start job is running for /sys/devices/virtual/misc/vmbus!hv_kvp
Dabei handelt es sich um einen Bug in Ubuntu (siehe hier). Dies kann momentan nur durch einen Workaround behoben werden. Dazu muss die systemd-Unit bearbeitet werden:
sed -i "s/^After=.*/After=systemd-remount-fs.service/" /etc/systemd/system/multi-user.target.wants/hv-kvp-daemon.service
Abschließend muss die geänderte Konfiguration noch neu eingelesen werden.
systemctl daemon-reload
Nach einem Neustart sollte die VM nun wieder normal und ohne Verzögerung booten.
Hinweis: Wenn es ein Update der o.g. „virtual-Pakete“ gibt, ist die systemd-Unit erneut anzupassen, da die geänderte Datei wieder durch das Update überschrieben wird.
QEMU Agent installieren
Ein wichtiger Punkt fehlt nun noch, der bereits weiter oben kurz angesprochen wurde: Auf dem Gast-System sollte nun noch der QEMU Agent installiert werden, damit eine optimierte Kommunikation zwischen VM-Host und -Gast möglich ist. Erst mit der Installation des Agents wird auch das sog. Balooning möglich, so dass der Speicher der virtuellen Maschine dynamisch angepasst werden kann (s.o.).
Der Agent wird auf dem Gast-System ganz einfach installiert:
apt update && apt install qemu-guest-agent
Nun muss nur noch dem Host-System bekannt gemacht werden, dass es den QEMU Agent nutzen kann. Dazu fahren wir die VM zunächst einmal herunter:
shutdown now
Zurück in der Weboberfläche von Proxmox markieren wir die VM im linken Menü und wählen hier Optionen.
Mit einem Doppelklick auf QEMU Guest Agent wird der Dialog zum Ändern der Einstellung geöffnet.
Hier aktivieren wir nun die Option QEMU Guest Agent benützen und schließen den Dialog mit OK.
Anschließend kann eine VM auch einfach über die Proxmox-Oberfläche mit dem Button Herunterfahren herunter gefahren werden und man kann beobachten, dass der Maschine nur so viel Speicher wie nötig zugewiesen wird.
Fazit
Damit ist die Einrichtung der virtuellen Maschine und die Installation von Ubuntu Server als Gast-Betriebssystems bereits abgeschlossen. Mit ein paar Schritten wurde das Gast-System noch auf die virtuelle Umgebung optimiert.
Nach erfolgter Ersteinrichtung empfiehlt es sich, direkt einen Snapshot der virtuellen Maschine anzufertigen (in den Einstellungen der VM unter Snapshots). Damit hat man direkt einen sauberen „Zwischenstand“.
Anschließend kann die virtuelle Maschine wie ein ganz normales System genutzt werden. Beispielsweise kann nun eine Nextcloud-Instanz auf dem System eingerichtet werden.
Wie sieht es bei euch aus? Nutzt ihr Proxmox (oder auch andere Virtualisierungs-Lösungen)? Welche Systeme werden hier bei euch virtualisiert? Hinterlasst mir dazu gern einen Kommentar.
Weiterführende Artikel
- Proxmox VE: Installation und Grundkonfiguration
- Proxmox VE: Ubuntu Server als Linux Container (LXC) installieren und einrichten
- Proxmox VE: Windows 11 als virtuelle Maschine installieren und einrichten
- Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten
Moin Moin,
vielen Dank mal wieder für den tollen Artikel. Gibt es einen konkreten Grund weshalb du VMs in Proxmox hostest? Gerade für Linux Umgebungen bieten sich LXC Container ja geradezu an. Ich habe auf meinem Proxmox eine ganze Menge an LXC Containern angelegt (Auch dank einiger deiner Blogeinträge) (ReverseProxy, Matrix, Nextcloud, Jitsi, Coturn, WebDAV Server für Passwortdatenbanken, piHole etc.) Habe mir dazu einen Container mit Grundkonfiguration erstellt, als Template geklont und das ist dann die Grundlage für alle Container. Performance- und Speichermäßig macht sich das wahrscheinlich auch bemerkbar. Hardware kann unter LXC auch in Grenzen durchgereicht werden. Proxmox ist wirklich Spitze, wenn ich daran denke was das manchmal für ein Krampf mit den Raspberrys war. Dann ist was fehlgeschlagen und alles musste neu installiert werden. Im Proxmox stell ich einfach ein Snapshot wieder her. Hat mir bei manchem Nextcloud Update den Hintern gerettet :-)
VG Thomas
Hi Thomas,
pssst…nicht schon die Infos vorwegnehmen. ;-)
Zu LXC-Containern und den Unterschieden zu „echten“ VM wird bald noch ein Artikel folgen.
Aber im Großen und Ganzen hast du schon Recht: LXC kann man sehr gut für „die vielen Kleinigkeiten“ nehmen, das läuft dann sehr viel ressourcenschonender als VMs.
Gruß,
Jan
…ups sorry :-) Bin gespannt, finde Deine Artikel wirklich sehr cool, Kompliment :-)
Hi,
nix sorry. Das ist denke ich eine Frage, die man sich immer stellt, wenn man sich anfangs mit Proxmox beschäftigt. ;-)
Gruß,
Jan
Hi,
ich habe mich bei manchen Diensten explizit für eine VM entschieden.
Z.B. bei der Wireguard-VPN, das will ich möglichst gut vom Rest des Systems abschotten.
Anderes Beispiel ist ioBroker.
Da musste ich an die VM 2 USB-Sticks durchreichen und da schien es mir erstmal mit der VM einfacher.
Das nächste Projekt ist eine Docker-VM, wo verschiedene Docker-Dienste laufen sollen.
Ich will eigentlich an dem Host-System (Proxmox) nicht viel verbiegen – es soll möglichst unberührt bleiben.
Tom
Vielen Dank für den sehr guten Artikel! Ich habe eine Frage zu der Zuordnung einer Netzwerk Bridge. Wenn ich während der Erstellung vmbr0 zuordne funktioniert alles tadellos. Möchte ich jedoch in einer Firewallregel für die VM das Interface mit vmbr0 konkretisieren kommt ein Fehler. Ich vermute das liegt daran das unter /etc/network/interfaces kein Eintrag für vmbr0 erstellt wird. Muss dieser Manuel nachgetragen werden? Interessanterweise greift die Firewall aber auch ohne die Zuweisung von vmbr0. Beim Host selber kann das Interface definiert werden, hier ist aber auch ein Eintrag in /etc/network/interfaces vorhanden. Beste Grüße :)
Hi,
die Option „Interface“ beim Erstellen einer Firewall-Regel bezieht sich immer auf die Netzwerk-Interfaces der VMs. „net0“ ist dabei das erste, „net1“ das zweite, etc. Normalerweise soll eine Regel ja auf alle Interfaces der VM greifen, daher einfach die Option Interfaces leer lassen.
Gruß,
Jan
Hallo Jan
Danke für den Artikel. Ich konnte dadurch noch einiges optimieren bei meinen VM’s. Beispielsweise die Geschichte mit dem qemu-guest-agent, welchernun endlich meine EspoCRM VM runterfahren, lässt damit ein vollständiges Backup gemacht werden kann.
Danke. Grüsse Gregor
Ich bin erst kürzlich auf deine Seite gestoßen. Mache bitte weiter so. Nahezu jeder Artikel ist interessant und lässt sich gut nachvollziehen.
Könntest du auch Mal einen Artikel über wireguard schreiben?
Viele Grüße
Hallo Jan,
mal eine andere Frage. Durch deine Artikel über Proxmox bin ich neugierig geworden und hab es ausprobiert und habe jetzt alle VMs auf Proxmox. Auch eine pfSense, da dies unter ESXI sehr gut lief. Jetzt hab ich nur ein Problem. Die Portfreigaben die ich in der pfSense mache komme anscheinend nicht in meiner OpenVPN-VM an. Weisst Du was ich machen muss damit das funktioniert? Ansonsten werd ich wohl oder übel wieder zu ESXI zurück müssen. Und danke für deine Artikel.
Gruss chris
Hi Chris,
puh, leider habe ich mit pfSense keinerlei Erfahrungen. Ich vermute aber mal eher, dass dies etwas mit den Netzwerk-Einstellungen zu tun hat. Hier kann ich aber nicht pauschal sagen, woran es liegen könnte. Hier müsste man analytisch vorgehen (sind die Maschinen im gleichen Netz-Segment, können die Maschinen sich gegenseitig anpingen, etc.).
Gruß,
Jan
Danke für nützliche Informationen (Newbie hier)
Wofür braucht mann eigentlich linux-tools-virtual und linux-cloud-tools-virtual?
Besteht den Fehler noch in Ubuntu 22.4.1LTS?
(Entschuldigung für mein schlechtes Deutsch)
Hi,
die beiden Pakete sind dafür da, dass die VM danach „weiß“, dass es in einer virtualisierten Umgebung läuft.
Der Fehler besteht bei Ubuntu 22.04 denke ich immer noch, wenn ich mich recht entsinne.
Gruß,
Jan
Hi,
danke für den Guide. Allerdings ist der kernel-Paramter `elevator=noop` zumindest bei aktuellen kernel-Versionen (ich habe hier 5.19) überflüssig:
[ 0.029906] kernel: Kernel parameter elevator= does not have any effect anymore.
Please use sysfs to set IO scheduler for individual devices.
Gruß
Sven