Ausgangslage

Eine Automation, die auf Benachrichtigungen angewiesen ist, sollte nicht davon abhängen, ob zufällig ein Windows-Rechner gerade eingeschaltet ist. Mein Cowork-Workflow mit Push-Benachrichtigungen lief bisher genau so – nur wenn der PC lief. Die Lösung: eine dedizierte, dauerhaft laufende VM im Proxmox-Cluster, mit grafischer Oberfläche, weil die Zielanwendung (Claude Desktop) eine Electron-App ist.

Was auf dem Papier nach einer Routine-Installation aussah, entwickelte sich zu einer kleinen Fehlersuche durch mehrere Schichten – vom Kernel bis zur virtuellen Hardware. Dieser Beitrag dokumentiert den kompletten Weg, inklusive aller Stolpersteine.

Problem

Mehrere Entscheidungen und Hürden mussten der Reihe nach genommen werden:

• Eine schlanke VM-Basis aufsetzen, ohne unnötigen Overhead
• Eine grafische Oberfläche nachrüsten, obwohl Cloud-Images bewusst minimal sind
• Die Anwendung selbst korrekt installieren
• Und am Ende: eine Funktion (Cowork mit lokalem Zugriff) zum Laufen bringen, die eine zusätzliche, verschachtelte Virtualisierungsebene braucht

Auflösung

1. Debian-VM per Cloud-Init erstellen

Statt einer klassischen ISO-Installation kam ein Helper-Script von community-scripts.github.io zum Einsatz, das automatisiert ein Debian-Cloud-Image herunterlädt und daraus eine VM erstellt:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/vm/debian-vm.sh)"

Im Dialog: Hostname setzen, Ziel-Node und VLAN wählen, und bei der Rückfrage „Configure the VM with Cloud-init?“ mit Yes bestätigen – das spart die manuelle Nachkonfiguration von Netzwerk und SSH-Zugang.

2. Grundkonfiguration nach dem ersten Boot

# Zeitzone und Locale
timedatectl set-timezone Europe/Zurich
sed -i 's/^# de_CH.UTF-8/de_CH.UTF-8/' /etc/locale.gen
locale-gen
update-locale LANG=de_CH.UTF-8

# QEMU Guest Agent für saubere Proxmox-Integration
apt update
apt install -y qemu-guest-agent openssh-server
systemctl enable --now qemu-guest-agent

Stolperstein 1 – SSH-Host-Keys nach Reboot. Cloud-Init-Images generieren Host-Keys mitunter bei jedem Neustart neu, was ständige Fingerprint-Warnungen auslöst. Fix:

cat > /etc/cloud/cloud.cfg.d/99-keep-ssh-hostkeys.cfg << 'EOF'
ssh_deletekeys: false
EOF

3. XFCE-Desktop nachrüsten

apt install -y task-xfce-desktop lightdm
systemctl enable lightdm

Die Installation eines vollständigen Desktop-Metapakets dauert deutlich länger, als der Paketname vermuten lässt – hier ist Geduld gefragt.

Stolperstein 2 – lightdm startet nicht, „no screens found“. Nach der Installation und einem Reboot blieb der Bildschirm schwarz. Die Logs (journalctl -u lightdm, /var/log/Xorg.0.log) zeigten den eigentlichen Fehler:

(EE) open /dev/dri/card0: No such file or directory
(EE) Screen(s) found, but none have a usable configuration.
(EE) no screens found

Der QXL-Grafikkarten-Treiber (nötig für das SPICE-Display der VM) fand keine passenden Kernel-Module. Der Grund: Das Cloud-Image bootet standardmässig einen abgespeckten *-cloud-amd64-Kernel ohne volle Grafiktreiber-Unterstützung. Der vollständige Desktop-Kernel war zwar bereits parallel installiert (linux-image-amd64), wurde aber von GRUB nicht als Standard gebootet:

dpkg -l | grep linux-image
# zeigt sowohl *-cloud-amd64 als auch den regulären *-amd64 Kernel

Fix – GRUB auf den vollständigen Kernel umstellen:

cat > /etc/default/grub.d/99-force-desktop-kernel.cfg << 'EOF'
GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 6.1.0-51-amd64"
EOF
update-grub
reboot

Nach dem Reboot: uname -r zeigte den Desktop-Kernel, /dev/dri/card0 existierte, und XFCE startete sauber.

Stolperstein 3 – Autologin-User falsch gesetzt. Die erste Autologin-Konfiguration zielte auf root:

# So NICHT, falls das Cloud-Image einen separaten User anlegt:
cat > /etc/lightdm/lightdm.conf.d/50-autologin.conf << 'EOF'
[Seat:*]
autologin-user=root
autologin-user-timeout=0
EOF

Das Cloud-Image hatte aber einen eigenen, per Cloud-Init angelegten Standard-User – nicht root. Root-GUI-Logins werden von vielen Distributionen ohnehin per PAM blockiert. Korrektur: den tatsächlichen Cloud-Init-User eintragen, dann funktionierte der automatische grafische Login beim Boot.

4. Claude Desktop installieren

curl -fsSLo /usr/share/keyrings/claude-desktop-archive-keyring.asc https://downloads.claude.ai/claude-desktop/key.asc
echo "deb [signed-by=/usr/share/keyrings/claude-desktop-archive-keyring.asc] https://downloads.claude.ai/claude-desktop/apt/stable stable main" | sudo tee /etc/apt/sources.list.d/claude-desktop.list
sudo apt update
sudo apt install claude-desktop

Stolperstein 4 – falsche Repo-URL aus einer nicht verifizierten Quelle. Ein erster Versuch mit einer geratenen Repo-Adresse endete in einem 404. Die korrekten Werte stehen im offiziellen Claude Help Center; wer nach dieser Anleitung installiert, sollte sicherheitshalber immer die aktuelle Doku statt einer irgendwo notierten URL verwenden – Paket-Repos ändern sich.

Zur Kontrolle lohnt sich ein Fingerprint-Check des Signing-Keys:

gpg --show-keys /usr/share/keyrings/claude-desktop-archive-keyring.asc

Der ausgegebene Fingerprint sollte mit der in der offiziellen Dokumentation genannten Zeichenfolge übereinstimmen.

Nach erfolgreicher Installation und erstem Login zeigt sich die App:

5. Claude Code (CLI) zusätzlich installieren

Wer neben der Desktop-App auch die terminalbasierte Variante möchte, installiert sie separat:

curl -fsSL https://claude.ai/install.sh | bash

Das ist der aktuell empfohlene Weg – eine frühere npm-basierte Installation (npm install -g @anthropic-ai/claude-code) wird von Anthropic mittlerweile als veraltet markiert, funktioniert zwar noch, erhält aber nicht mehr automatisch Updates auf demselben Weg. Nach der Installation direkt im Projektverzeichnis mit claude starten.

6. Cowork mit lokalem Zugriff: KVM-Voraussetzungen

Cowork mit Zugriff auf lokale Dateien braucht auf Linux zusätzlich eine eigene, verschachtelte QEMU/KVM-Sandbox innerhalb der VM:

apt install -y qemu-system-x86 ovmf qemu-system-common
usermod -aG kvm <username>

Stolperstein 5 – Paketname für virtiofsd. Auf Debian 12 ist virtiofsd kein eigenständiges Paket, sondern in qemu-system-common enthalten (erst ab Debian 13 separat ausgelagert). Ein direktes apt install virtiofsd schlägt auf Debian 12 fehl – es reicht, qemu-system-common zu installieren.

Verifizieren, dass KVM-Beschleunigung tatsächlich funktioniert:

apt install -y cpu-checker
kvm-ok

Stolperstein 6 – Cowork startete trotz allem nicht, VM-Node-Wechsel als Lösung. Trotz bestätigter KVM-Funktion und korrekter Gruppenmitgliedschaft blieb die lokale Cowork-VM auf einem bestimmten Proxmox-Node hartnäckig als „nicht unterstützt“ klassifiziert. Nach dem Verschieben der VM auf einen anderen Node im Cluster – mit einer anderen CPU-Generation – funktionierte es sofort. Das deutet stark darauf hin, dass Cowork’s interne Kompatibilitätsprüfung tiefer liegende CPU-Virtualisierungs-Features prüft, als ein einfacher kvm-ok-Test abdeckt (etwa Nested-Virtualization-Feinheiten, die je nach CPU-Generation unterschiedlich vollständig unterstützt sind). Falls also KVM grundsätzlich läuft, Cowork aber trotzdem hartnäckig „nicht unterstützt“ meldet: einen Node-Wechsel auf andere Hardware in Betracht ziehen, falls der Cluster das hergibt.

Lessons Learned

• Cloud-Init-Images sind bewusst minimal – inklusive eines abgespeckten Kernels ohne volle Grafiktreiber. Wer eine GUI braucht, muss aktiv gegensteuern, notfalls bis auf Kernel-/GRUB-Ebene.
• „Installiert“ heisst nicht „wird auch gebootet“. Zwei parallel installierte Kernel-Pakete sagen nichts darüber aus, welcher tatsächlich aktiv ist – das lohnt sich, nach jeder grösseren Änderung explizit mit uname -r zu verifizieren.
• Paketnamen unterscheiden sich zwischen Debian-Versionen, gerade bei noch jungen Komponenten wie virtiofsd – ein fehlgeschlagenes apt install ist nicht automatisch ein grundsätzliches Problem, sondern manchmal nur ein falscher Paketname für die jeweilige Version.
• Nicht verifizierte URLs aus dem Gedächtnis oder Vermutungen führen zu Fehlern – bei Paket-Repositories lohnt sich immer der Blick in die aktuelle offizielle Dokumentation.
• „KVM funktioniert“ ist nicht dasselbe wie „alle für verschachtelte Virtualisierung nötigen CPU-Features werden unterstützt“. Unterschiedliche CPU-Generationen innerhalb desselben Clusters können hier zu unterschiedlichem Verhalten führen, selbst wenn Basis-Tests wie kvm-ok überall grün sind.

Fazit

Was als einfache „App installieren“-Aufgabe begann, führte durch mehrere Ebenen – Kernel-Auswahl, Bootloader-Konfiguration, Benutzerrechte, Paketnamen-Unterschiede zwischen Debian-Versionen und letztlich CPU-Feature-Kompatibilität innerhalb des Clusters. Jede einzelne Hürde für sich war überschaubar, in Summe aber deutlich mehr als die „eine Zeile Terminal-Befehl“, die man sich zu Beginn vorstellt. Am Ende läuft die VM zuverlässig, mit grafischer Oberfläche, Autologin und voll funktionsfähigem Cowork inklusive lokalem Dateizugriff – und mit einer sauberen Dokumentation für das nächste Mal.