Virtualisierung auf dem Desktop gehört für mich zum täglichen Werkzeug. Ich teste damit Distributionen, baue mir saubere Entwicklungsumgebungen und schaue mir Software an, die ich nicht direkt auf meinem Arbeitsgerät haben möchte. Über die Jahre habe ich so ziemlich alles ausprobiert, was es auf Linux gibt, und bin bei VMware Workstation Pro hängen geblieben. Das ist eine bewusste Entscheidung, und ich erkläre dir gerne, warum.
VirtualBox war lange mein Einstieg, so wie wahrscheinlich bei den meisten. Es ist gratis, schnell installiert und tut, was es soll. Sobald es aber um Leistung, sauberes 3D oder ein wirklich rundes Zusammenspiel mit dem Gastsystem geht, merkt man die Grenzen. Dazu kommt das Theater mit dem Extension Pack und dessen Lizenz, das mir ehrlich gesagt nie gefallen hat. KVM mit QEMU und virt-manager ist die andere Seite des Spektrums. Technisch ist das hervorragend, es steckt direkt im Kernel, die Leistung ist nativ und alles ist offen. Wenn ich reine Linux-Server-VMs laufen lassen will, ist KVM oft die beste Wahl. Nur ist die Desktop-Erfahrung ist unschön. Snapshots, Gerätekonfiguration und vor allem eine wirklich gute Bildschirm- und 3D-Anbindung im Gast kosten dort spürbar mehr Bastelei.
Und genau hier spielt VMware seine Stärken aus. Die Oberfläche ist aufgeräumt, Snapshots und Linked Clones funktionieren zuverlässig und schnell, die Gastunterstützung ist erstklassig und die VMware Tools sorgen für eine Integration, die sich einfach fertig anfühlt. Geteilte Ordner, Drag and Drop, dynamische Auflösung, das läuft alles ohne langes Suchen. Der einzige echte Nachteil war früher der Preis. Den gibt es nicht mehr, denn seit November 2024 ist VMware Workstation Pro für alle kostenlos, auch für den kommerziellen Einsatz. Damit fällt das letzte Argument gegen VMware weg, und ich kann es ohne Vorbehalte empfehlen.
VMware Workstation Pro herunterladen
Der Download läuft heute nicht mehr über die alte VMware-Seite, sondern über das Broadcom Support Portal. Du brauchst dafür ein kostenloses Broadcom-Konto, das du dir in wenigen Minuten anlegst. Einen Lizenzschlüssel benötigst du nicht mehr, bei der Installation wählst du einfach die Option für die persönliche oder kommerzielle Nutzung aus. Die aktuelle Hauptversion trägt die kalenderbasierte Bezeichnung 26H1, das Nummernschema mit 17.x gehört der Vergangenheit an.
Nach dem Login findest du den Download unter der VMware Cloud Foundation im Bereich der eigenen Downloads. Für Linux lädst du das Bundle herunter und machst es ausführbar, danach startest du den Installer mit Root-Rechten.
chmod +x VMware-Workstation-Full-*.bundle
sudo ./VMware-Workstation-Full-*.bundle
Beim ersten Start baut VMware die nötigen Kernel-Module selbst. Auf einem System ohne Secure Boot ist damit alles erledigt. Hast du Secure Boot aktiv, und das ist bei einem modernen Ubuntu der Standard, kommt jetzt der Teil, an dem viele hängen bleiben.
Warum die Module nicht laden
VMware braucht zwei eigene Kernel-Module, nämlich vmmon für die virtuelle Maschine selbst und vmnet für das Netzwerk. Diese Module werden beim Build frisch kompiliert und sind dabei nicht signiert. Secure Boot wiederum hat genau eine Aufgabe: Es lässt nur signierten Code in den Kernel. Ein unsigniertes Modul wird konsequent abgewiesen, und VMware meldet, dass es die Module nicht laden kann.
Die schnelle Lösung wäre, Secure Boot einfach abzuschalten. Das funktioniert, ich finde es aber unsauber, weil du damit einen sinnvollen Schutzmechanismus deaktivierst. Der bessere Weg ist, die Module mit einem eigenen Schlüssel zu signieren und diesen Schlüssel bei Secure Boot anzumelden. Klingt nach viel Arbeit, ist aber einmalig gemacht und lässt sich danach komplett automatisieren.
Einen eigenen Signierschlüssel erzeugen
Zuerst erstellst du ein Schlüsselpaar. Die Datei MOK.priv ist dein privater Schlüssel zum Signieren, MOK.der ist das passende Zertifikat, das du später bei Secure Boot hinterlegst. MOK steht für Machine Owner Key, also den Schlüssel, mit dem du als Besitzer deiner Maschine eigenem Code vertraust.
cd ~
openssl req -new -x509 -newkey rsa:2048 \
-keyout MOK.priv -outform DER -out MOK.der -nodes \
-days 36500 -subj "/CN=VMware Module Signing/"
Damit der spätere Automatismus die Dateien zuverlässig findet, legst du sie an einen festen, geschützten Ort und schränkst die Rechte am privaten Schlüssel ein.
sudo mkdir -p /root/vmware-sign
sudo mv MOK.priv MOK.der /root/vmware-sign/
sudo chmod 600 /root/vmware-sign/MOK.priv
Das Signier-Skript anlegen
Statt die Module von Hand zu signieren, schreibe ich ein kleines Skript, das die Arbeit übernimmt. Es prüft zuerst, ob sich die Module bereits laden lassen. Falls nicht, baut es sie neu, signiert sie mit deinem Schlüssel und lädt sie anschliessend. Genau dieses Skript ist später der Kern der Automatisierung.
sudo nano /usr/local/sbin/vmware-sign-modules.sh
In die Datei kommt folgender Inhalt:
#!/bin/bash
KEY=/root/vmware-sign/MOK.priv
CERT=/root/vmware-sign/MOK.der
KBUILD=/usr/src/linux-headers-$(uname -r)
# Wenn die Module schon ladbar sind, ist nichts zu tun
if modprobe vmmon 2>/dev/null && modprobe vmnet 2>/dev/null; then
exit 0
fi
# Sonst neu bauen
vmware-modconfig --console --install-all
# Signieren und laden
for mod in vmmon vmnet; do
modpath=$(modinfo -n "$mod" 2>/dev/null) || continue
"$KBUILD/scripts/sign-file" sha256 "$KEY" "$CERT" "$modpath"
modprobe "$mod"
done
Danach machst du das Skript ausführbar.
sudo chmod +x /usr/local/sbin/vmware-sign-modules.sh
Den Systemd-Service einrichten
Damit das Skript bei jedem Start automatisch läuft, packst du es in einen kleinen Systemd-Service. Das ist der Punkt, der dir bei jedem zukünftigen Kernel-Update die Arbeit abnimmt.
sudo nano /etc/systemd/system/vmware-sign-modules.service
Der Inhalt sieht so aus:
[Unit]
Description=VMware Kernel-Module bauen und signieren
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/vmware-sign-modules.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Anschliessend aktivierst du den Service. Bewusst ohne den Zusatz, ihn sofort zu starten, denn er soll erst nach dem Reboot laufen, wenn dein Schlüssel auch wirklich anerkannt ist.
sudo systemctl daemon-reload
sudo systemctl enable vmware-sign-modules.service
Den Schlüssel bei Secure Boot anmelden
Jetzt fehlt noch der entscheidende Schritt, nämlich Secure Boot beizubringen, dass es deinem Schlüssel vertrauen soll. Das übernimmt mokutil.
sudo mokutil --import /root/vmware-sign/MOK.der
Hier wirst du nach einem Passwort gefragt. Das ist ein einmaliges Passwort, das du gleich beim nächsten Start im MOK Manager noch einmal eingibst. Es muss also nichts Kompliziertes sein, du musst es dir nur kurz merken.
Und jetzt der wichtigste Hinweis dieses Abschnitts: Der MOK Manager läuft vor dem eigentlichen Systemstart und kennt nur das US-Tastaturlayout, völlig egal, was du sonst eingestellt hast. Auf einer Schweizer Tastatur sind dadurch zum Beispiel z und y vertauscht, und Sonderzeichen wie Bindestrich, Schrägstrich oder Umlaute landen an ganz anderen Stellen. Halte das Passwort darum bewusst simpel, am besten nur Kleinbuchstaben und Zahlen ohne Sonderzeichen, und denke beim Tippen an den vertauschten Platz von z und y. Sonst scheitert das Enrollment, weil das Passwort scheinbar nicht stimmt, obwohl du es eigentlich richtig im Kopf hast.
Reboot und Enrollment
Beim Neustart erscheint ein blaues Menü, der sogenannte MOK Manager. Dort wählst du den Punkt zum Enrollen des Schlüssels, bestätigst ihn und gibst das zuvor gesetzte Passwort ein. Wichtig ist, dass dieses Menü nur direkt nach dem Reboot erscheint und nur ein paar Sekunden stehen bleibt. Verpasst du es, bootet das System normal weiter und der Schlüssel bleibt unangemeldet. In dem Fall meldest du den Schlüssel einfach noch einmal mit mokutil an und startest erneut.
sudo reboot
Nach diesem letzten Neustart läuft alles von selbst. Der Service merkt beim Hochfahren, dass die Module noch nicht signiert sind, baut sie, signiert sie mit deinem nun anerkannten Schlüssel und lädt sie. VMware startet danach ohne Murren.
Der eigentliche Gewinn: künftige Kernel-Updates
Der schönste Teil zeigt sich erst später. Bei jedem Kernel-Update werden die VMware-Module normalerweise unsigniert neu gebaut, und ohne Vorkehrung stehst du jedes Mal wieder vor der Fehlermeldung. Dank des Service passiert das nicht mehr. Nach einem Update baut und signiert er die Module beim nächsten Start ganz von allein, und du merkst von der ganzen Sache schlicht nichts. Einmal eingerichtet, nie wieder daran gedacht, und genau so soll es sein.
Falls der Modul-Build nach einem sehr neuen Kernel einmal ganz abbricht, liegt das übrigens nicht an Secure Boot, sondern an Kompatibilitätsproblemen zwischen VMware und dem Kernel. Dann helfen gepatchte Host-Module aus der Community weiter, die du auf demselben Weg signierst. Bei mir war das bislang aber nicht nötig, die aktuellen Versionen vertragen sich gut mit den neueren Kerneln.
