Linux und Windows HelpDesk

Festplatte in Host und (mehreren) VMs einbinden.

Benötigt man eine Festplatte gleichzeitig auf dem Host und in einer oder mehreren VMs, wird zumeist auf die Netzwerkprotokolle NFS oder CIFS, also Samba zurückgegriffen.
Eine weitere und recht einfach einzurichtende Möglichkeit, bietet das virtio-9p genanten QEMU 9P Filesystem Protokoll.

Auf dem Host ist dafür zunächst die Konfigurationsdatei der jeweiligen VM unter /etc/pve/local/qemu-server/<vmid>.conf mit dem Editor zu öffnen und die folgende Zeile einzufügen. Die VM sollte dabei nicht in Betrieb sein.
Wenn es in der Konfigurationsdatei bereits eine Zeile "args:" gibt, dann wird diese mit den folgenden Angaben und durch ein Komma getrennt, nur erweitert. Auch mehrere 9p-Volumes können auf diese Weise hintereinander Aufgeführt werden.

args: -fsdev local,security_model=mapped-xattr,id=fsdev0,multidevs=remap,path=/mnt/sdX,fmode=0644,dmode=0755 -device virtio-9p-pci,fsdev=fsdev0,mount_tag=fsdev0_sdX

Diese Punkte sind individuell an das System anzupassen.

security_model
Bei der von offizieller Seite nicht empfohlenen Angabe "passthrough", werden Dateien und Verzeichnisse mit unverändertem Besitzer und Rechten auf dem Host abgelegt. Verwendet man stattdessen "mapped-xattr" als security model, haben die abgelegten Dateien nur eingeschränkte Rechte. Default werden Dateien mit den Rechten 600 und Verzeichnisse mit 700 auf dem Host abgelegt.
id
Die ID kann mehr oder weniger frei definiert werden. Richtet man mehrere Freigaben ein, sollten die IDs unterschiedlich sein.
path
Hier ist der Mountpoint der Festplatte auf dem Host anzugeben. Es ist ebenso möglich, nur einen einzelnen Ordner als Freigabe anzugeben.
fmode / dmode
Hier können die Rechte definiert werden, die Dateien (fmode) und Verzeichnisse (dmode) auf dem Host erhalten, wenn "mapped-xattr" als security_model verwendet wird. Es ist zu beachten, dass die Angabe vierstellig, also mit führender 0 erfolgen muss. Diese Angaben werden nur bei "mapped" Security Modelen angewendet und verursachen eine Fehlermeldung, wenn "passthrough" verwendet wird. (Aufgefallen ist mir, dass nur User und Gruppenrechte gesetzt werden. Angaben wie 0644 oder 0755 ergeben auf dem Host 0640 und 0750 als Rechte. Das ist evtl. ein Bug, eine Erklärung dazu fand ich bisher nicht.)
fsdev
Hier wird der bereits unter ID angegebene Wert eingetragen.
mount_tag
Auch dieser Wert kann frei definiert werden und entspricht der Angabe der Partition im mount Aufruf bzw. in der /etc/fstab, auf dem Gast-System.

Die VM kann nun wieder gestartet werden und sollte dabei keinerlei Auffälligkeiten zeigen.
Mit den folgenden Befehlen wird das Verzeichnis für den Mountpoint erstellt und die Freigabe auf dem Gast gemountet. Die angegebene Partition im Aufruf, ist entspricht der Angabe mount_tag welche in der Datei <vmid>.conf angegeben wurde, anzupassen.

# mkdir /mnt/sdX
# mount -t 9p -o trans=virtio,version=9p2000.L fsdev0_sdX /mnt/sdX

Möchte man erreichen, dass die Freigabe automatisch beim booten der VM gemountet wird, fügt man in die Datei /etc/fstab folgende Zeile mit entsprechend angepasster Angabe für Partition und Mountpoint hinzu.

fsdev0_sdX /mnt/sdX 9p trans=virtio,version=9p2000.L,msize=512000,nobootwait,rw,nofail,_netdev 0 0

Die Option nofail bewirkt, dass keine Kernel panic ausgelöst wird, wenn eine Freigabe beim Startprozess nicht gemountet werden kann. In der Regel ist es nötig die Option _netdev anzugeben, damit die Freigabe beim Boot gemountet wird. Beim Eisfair-Server habe ich beobachtet, dass diese Option den gegenteiligen Effekt hatte und entfernt werden musste. Wird eine Freigabe beim Boot nicht gemountet, kann aber mit einem händischen Mount Befehl eingebunden werden, dann sollte die Option _netdev entfernt werden.

Bei meinem Eisfair-Server habe ich außerdem beobachtet, dass beim Start gelegentlich nicht alle 9p-Volumes gemountet werden, wenn mehrere in der /etc/fstab angegeben sind. Ein späteres Mounten der beim Systemstart nicht gemounteten 9p-Volumes ist aber problemlos möglich. Aus diesem Grund habe ich das folgende Script erstellt, welches per cronjob @reboot nach dem Systemstart ausgeführt wird, und bei allen in der /etc/fstab angegebenen 9p-Volumes den Mount-Status überprüft und für diese bei Bedarf das Mounten nachholt.

#!/bin/bash
# ------------------------------------------------------------------------------------------
# Mounten von QEMU 9pfs
#
# Es kann vorkommen, dass gelegentlich nicht alle QEMU 9p Volumes beim Systemstart gemountet
# werden, obwohl sie in der /etc/fstab aufgeführt sind. Lassen sich diese QEMU Volumes nach
# dem Systemstart problemlos "händisch" mounten, so kann man mit diesem Script per Cronjob
# das oder die QEMU Volumes nachträglich mounten lassen. Man legt dieses Script unter
# /usr/local/bin/mount9p.sh ab und erstellt anschließend per crontab -e einen Cronjob mit
# dem Inhalt:
# @reboot /usr/local/bin/mount9p.sh
# ------------------------------------------------------------------------------------------
qemumount=$(sed '/^#/d' /etc/fstab | grep "9p" | cut -d " " -f1)
for i in ${qemumount}; do
    if ! findmnt "$i" &>/dev/null; then
        mount "$i"
    fi
done

Dieses Script einfach in /usr/local/bin/mount9p.sh erstellen und per crontab -e einen entsprechenden @reboot Cronjob erstellen.

An einer Unterstützung für Windows-Gäste wird lt. QEMU-Dokumentation noch gearbeitet. MacOS-Gäste werden lt. den dortigen Angaben seit QEMU 7.0 unterstützt.
Ab Proxmox 8.4 wird virtiofs unterstützt und kann direkt in der Proxmox-GUI eingerichtet werden. Deshalb und wegen der wesentlich besseren Leistung, sollte virtiofs ab PVE 8.4 bevorzugt werden.