- Seit Proxmox VE 8.1/8.2 lässt sich das Clipboard für die noVNC-Konsole aktivieren. Standardmäßig ist es aber ausgeschaltet.
- Aktivierung per GUI oder Kommandozeile. Unter Hardware → Display → Advanced oder per
qm set <vmid> --vga std,clipboard=vnc, plus spice-vdagent im Linux-Gast bzw. Spice Guest Tools unter Windows. - Funktioniert nur mit laufender grafischer Sitzung im Gast. Für headless Server hilft die serielle Konsole mit xterm.js.
- Vor QEMU 10.1 blockiert das VNC-Clipboard die Live-Migration. Ab Proxmox VE 9.1 ist das kein Thema mehr.
- Gehört in die VM-Vorlage. Nicht erst in die Incident-Checkliste.
Wer eine ISO-27001-Zertifizierung im Haus hat, kennt die Vorgabe: Auch root und die lokalen Admin-Konten bekommen lange, komplexe Passwörter, und gewechselt werden sie ebenfalls nach Richtlinie. Im Passwort-Manager ist das alles kein Problem. Zum Problem wird es an der Proxmox-Konsole: Die VM ist per SSH oder RDP nicht erreichbar, der Notfall-Login muss über noVNC laufen – und jetzt darf eine Kolonne aus Zahlen, Zeichen und Sonderzeichen abgetippt werden, bei der nach dem dritten Fehlversuch niemand mehr weiß, ob das Y im Gast gerade ein Z ist. Einfügen? Geht nicht. Jedenfalls nicht ab Werk.
Dabei kann Proxmox VE das längst. Seit Version 8.1 bringt es eine Clipboard-Unterstützung für die noVNC-Konsole mit, seit 8.2 lässt sie sich auch in der GUI einschalten. Trotzdem bleibt sie in den meisten Umgebungen ungenutzt, was weniger am fehlenden Bedarf liegt als daran, dass sie hinter dem Advanced-Haken der Display-Einstellungen wohnt. Einen ehrlichen Haken hat die Sache außerdem, dazu weiter unten.
So wird das Clipboard aktiviert
In der GUI sitzt die Einstellung pro VM unter Hardware → Display: erst unten den Haken bei Advanced setzen, dann im Feld Clipboard den Wert VNC auswählen. Auf der Kommandozeile geht es schneller:
qm set <vmid> --vga std,clipboard=vncDas std dabei durch den Display-Typ ersetzen, der ohnehin konfiguriert ist – es zählt allein der Teil clipboard=vnc. Damit im Gast auch jemand ans Telefon geht, braucht es dort einen Agenten, der das Clipboard entgegennimmt. Unter Linux übernimmt das spice-vdagent:
# Debian/Ubuntuapt install spice-vdagent# RHEL/Alma/Rockydnf install spice-vdagentWindows-Gäste bekommen die Funktion über die Spice Guest Tools, die bei den meisten Setups ohnehin zusammen mit den VirtIO-Treibern auf der Platte landen.
Wichtig: Die Änderung greift erst nach einem vollständigen Stop und Start der VM, weil QEMU das nötige Gerät erst beim Kaltstart anlegt – ein Reboot aus dem Gast heraus reicht nicht. Danach taucht in der noVNC-Konsole links in der Seitenleiste ein Clipboard-Symbol auf. Passwort aus dem Passwort-Manager hineinkopieren, drüben einfügen, fertig. Das funktioniert in beide Richtungen.
Vier Stolpersteine aus der Praxis
Der größte zuerst, und das ist der angekündigte Haken: Das VNC-Clipboard braucht im Gast eine laufende grafische Sitzung. Der spice-vdagent klinkt sich in X11 oder Wayland ein – am Anmeldebildschirm der Windows-VM und am grafischen Linux-Login klappt das Einfügen also, auf der nackten Text-Konsole eines headless Servers dagegen nicht. Dort existiert schlicht kein Clipboard, in das der Agent etwas einfügen könnte. Für diese VMs gibt es einen anderen Weg, dazu gleich mehr.
Zweitens der Zeitpunkt: Wer das Setting erst konfiguriert, wenn der Notfall schon da ist, hat doppelt schlechte Karten. Die VM müsste für die Änderung ausgerechnet jetzt einmal komplett aus und wieder an, und ohne laufenden Agenten im Gast passiert ohnehin nichts. Deshalb gehört die Einstellung in die VM-Vorlage beziehungsweise ins Provisionierungs-Playbook, nicht in die Incident-Checkliste. Bei uns steht sie im Standard, seit uns eine hängende VM zu einem längeren Konsolen-Einsatz gezwungen hat.
Drittens der Display-Typ: Anders als manche Anleitung behauptet, ist qxl keine Voraussetzung – std oder virtio funktionieren genauso. Nur wer seine VMs über SPICE bedient, sollte wissen, dass clipboard=vnc das gewohnte SPICE-Clipboard ersetzt. Beides gleichzeitig gibt es nicht.
Und viertens ein Punkt für Cluster-Betreiber: Mit einer QEMU-Maschinenversion unter 10.1 blockiert das aktivierte VNC-Clipboard die Live-Migration, die VM gilt dann als an lokale Ressourcen gebunden. Erst ab QEMU 10.1 (ausgeliefert mit Proxmox VE 9.1) wandern solche VMs wieder live von Node zu Node. Wer älter unterwegs und auf Live-Migration angewiesen ist, wägt hier kurz ab, bevor das Setting in die Vorlage kommt.
Copy & Paste ohne GUI: serielle Konsole plus xterm.js
Für headless Linux-VMs ohne grafische Oberfläche führt der Weg zum Einfügen über eine serielle Konsole. Die richtet Proxmox mit einer Zeile ein:
qm set <vmid> --serial0 socketIm Gast kommt dann noch console=tty0 console=ttyS0,115200 in die GRUB-Kernelzeile (/etc/default/grub, danach update-grub bzw. grub2-mkconfig) und die VM einmal neu gestartet. Ab jetzt steht in der Web-UI neben noVNC auch xterm.js als Konsole zur Verfügung – ein echtes Browser-Terminal, in dem sich Text direkt einfügen lässt, Login-Prompt inklusive. Damit ist das Passwort-Szenario auch für CLI-only-VMs abgedeckt, ganz ohne Agenten im Gast.
Einmal einrichten, dann vergessen
Ein Konfigurationswert, ein Paket im Gast, einmal Stop/Start – mehr ist es nicht. Bezahlt macht sich das immer dann, wenn es hektisch wird und ein komplexes Passwort oder ein langer Befehl fehlerfrei in einer Konsole landen muss, ohne dass man sich über Tastaturlayout und Sonderzeichen die Pest an den Hals ärgert. Warum wir zuletzt trotzdem länger vor einer Konsole saßen – eine hängende VM, kein SSH, viel dmesg –, beschreiben wir im zweiten Artikel dieser Reihe: eine Fehlersuche, die bei journald-Coredumps begann und bei einer einzigen Zeile VM-Konfiguration endete.
