VirtIOFS ist das Beste, was Sie in Proxmox noch nicht nutzen

Wer tief in der Welt der Proxmox-Virtualisierung steckt, hat sich vermutlich schon an Containern, VMs und vielleicht sogar an einem selbstgebauten Ceph-Cluster oder zweien versucht. Aber es gibt ein unauffälliges Feature, das bisher unter dem Radar geflogen ist und ehrlich gesagt viel mehr Aufmerksamkeit verdient: VirtIOFS.

Für viele Nutzer ist VirtIOFS still und leise zum Standardweg geworden, um die Lücke zwischen Host- und Gast-Betriebssystem zu überbrücken – besonders bei der Dateifreigabe. Und wer bislang bei den altbewährten Ansätzen wie Samba oder NFS geblieben ist, verpasst vielleicht eine der einfachsten und schnellsten Methoden, um Shared Folders in den eigenen virtuellen Maschinen zum Laufen zu bringen.

Also, was ist VirtIOFS überhaupt?

Wir wollen uns nicht zu sehr in technischer Dokumentation verlieren. Im Kern ist VirtIOFS ein Shared File System, das speziell für VMs gebaut wurde. Anders als ältere Methoden (hallo, NFS aus den 2000ern) ist VirtIOFS dafür ausgelegt, über den VirtIO-Transport zu laufen, der in QEMU/KVM-Umgebungen verwendet wird. Was das für Sie bedeutet: superschneller, latenzarmer Zugriff auf Dateien vom Host-System aus innerhalb Ihrer Gast-VMs.

Es ist die Art von Sache, die einfach funktioniert. Und für alle, die mit den Eigenheiten von LXC-Containern gekämpft oder versucht haben, sich Workarounds für persistenten Shared Storage zusammenzubasteln, kann sich VirtIOFS wie eine Erlösung anfühlen.

Warum es an Fahrt gewinnt

Ein Nutzer hat es perfekt zusammengefasst: „Ich bin bei LXCs hängengeblieben, nur weil ich damit einfach einen Host-Ordner gleichzeitig mit mehreren Containern teilen konnte. Aber LXC brauchte zusätzliche Konfiguration im Vergleich zu VMs, etwa beim Einsatz von unprivileged und beim Nutzen von VPNs wie Tailscale."

Das ist die Geschichte vieler Proxmox-Nutzer. Container sind großartig, bis sie es nicht mehr sind. Docker Swarm in einem LXC laufen zu lassen, kann schnell unübersichtlich werden, besonders wenn man mit VPNs jongliert oder mit unprivilegierten Rechten sandboxt. VMs bieten mehr Flexibilität und Isolation, hatten aber historisch keinen guten, unkomplizierten Weg zur Dateifreigabe – bis VirtIOFS kam.

Als dieser Nutzer anfing, von Docker Swarm in LXC zu Alpine-VMs zu wechseln, änderte sich alles. Shared Storage mit VirtIOFS einzurichten war schnell, einfach und funktionierte einfach … so wie es sollte. Selbst denselben Host-Ordner in eine Desktop-Linux-VM einzuhängen? Kein Problem. Performance? „Großartig."

Diese Erfahrung ist keine Ausnahme.

Ein anderer Nutzer berichtete, er habe „sofort alles auf VirtIOFS umgestellt", als Proxmox native Unterstützung ausrollte. Keine Stolpersteine. Kein Bedauern.

Anwendungsfälle aus der Praxis

Es zeichnet sich ein Muster ab. Proxmox-Nutzer machen einige interessante Dinge mit VirtIOFS:

• ZFS-Datasets vom Host in Gast-VMs weiterreichen
• Docker in vollwertigen Linux-VMs (statt in Containern) mit über VirtIOFS eingehängten Volumes laufen lassen
• Persistenten Storage zwischen mehreren VMs teilen – ohne Samba-Freigaben, ohne Aufwand
• Es sogar auf Windows-Gästen einsetzen für massive Dateiübertragungen (wenn auch nicht immer reibungslos – dazu gleich mehr)

Ein Nutzer schilderte zum Beispiel folgendes Setup: Proxmox-Host auf ZFS, Datasets über VirtIOFS an eine VM freigegeben, die sie dann als persistente Docker-Volumes nutzt. Die Performance schlägt vielleicht nicht rohen Block-Storage über VirtIO SCSI, aber was die einfache Nutzung angeht? Kaum zu schlagen.

Ein anderer Nutzer ging aufs Ganze: „Ich nutze VirtIOFS auf einem ZFS-RAIDZ2-3-HDD-Storage-Set als Hauptdatenlaufwerk für eine Ubuntu-VM." Die VM selbst liegt auf einer separaten SSD, während Datasets nach Bedarf eingespeist werden. Einfach. Sauber. Funktional.

Aber es ist nicht alles perfekt

Nicht jeder hat eine reibungslose Erfahrung. Ein Nutzer wies auf eine Performance-Lücke hin: „Beim Schreiben auf das VirtIO-SCSI-Laufwerk einer VM bekomme ich 1,5 GB/s, aber VirtIOFS fällt auf rund 150 MB/s ab." Das ist ein ziemlich deutlicher Unterschied – und etwas, das man im Hinterkopf behalten sollte, wenn intensive Datei-I/O geplant ist.

Ein anderer stieß auf Stabilitätsprobleme beim Übertragen von Terabytes an Daten über VirtIOFS an eine Windows-VM. Nach mehreren Hundert Gigabyte fror die VM ein – möglicherweise wegen Treiberlimitierungen oder Problemen unter hoher Last. Es lohnt sich festzuhalten, dass der Windows-Support noch reift und die Ergebnisse je nach Gast-Konfiguration variieren können.

Also ja, VirtIOFS ist nicht perfekt. Aber die Probleme, die Nutzer sehen, scheinen entweder Randfälle zu sein (massive Dateitransfers, Treiber-Bugs unter Windows) oder Kompromisse für mehr Einfachheit.

Der versteckte Vorteil: Einfachheit

Seien wir ehrlich – Samba sauber einzurichten ist mühsam. NFS kann zickig sein, besonders bei Berechtigungen und Netzwerk. LXC-Bind-Mounts sind großartig, bis man bessere VM-Isolation braucht. VirtIOFS umgeht das alles.

Ein Nutzer, der neu bei Proxmox war, gab zu, dass er VirtIOFS für alles gewählt hat, weil er die Alternativen schlicht nicht kannte. Und? Es hat bestens funktioniert.

Manchmal erlaubt es einem, den alten Weg nicht zu kennen, direkt zum besseren zu springen.

Für Neueinsteiger ist das Gold wert. Es gibt weniger Reibung, weniger bewegliche Teile, und einen Einrichtungsprozess, der einen nicht dazu zwingt, tief in obskure Proxmox-Foren einzutauchen oder Systemd-Mount-Units aus einem fünf Jahre alten Blogpost zu entschlüsseln.

Was ist mit der Performance?

Zurück zur früheren Beschwerde: Ist VirtIOFS „langsam"?

Kommt drauf an.

Bei rohen IOPS und Durchsatz hat VirtIO SCSI mit Block-Storage weiterhin die Nase vorn. Aber VirtIOFS soll Block-Storage nicht ersetzen – es geht um Zugriff auf Dateiebene. Wer eine große Zahl kleinerer Dateien liest und schreibt oder einfach geteilten Zugriff auf Config-Ordner, App-Daten oder Docker-Volumes braucht, für den ist es schnell genug. Und für viele Nutzer ist der Kompromiss bei der rohen Geschwindigkeit den einfacheren Aufbau und die einfachere Nutzung absolut wert.

In den meisten realen Szenarien läuft VirtIOFS gut genug, dass es sich nicht wie ein Flaschenhals anfühlt – besonders wenn man sein System nicht mit riesigen Transfers an die Grenze treibt.

Fazit: Sollten Sie es nutzen?

Wenn Sie Proxmox-Nutzer sind und VirtIOFS noch nicht ausprobiert haben, ist jetzt der richtige Moment.

• Brauchen Sie einen schnellen Weg, um Host-Daten mit VMs zu teilen? Nutzen Sie VirtIOFS.
• Wollen Sie von Containern zu VMs wechseln, ohne die einfache Storage-Freigabe zu verlieren? Nutzen Sie VirtIOFS.
• Betreiben Sie Docker in VMs? VirtIOFS macht persistente Volumes schmerzfrei.

Es geht nicht darum, Ihr gesamtes Setup neu zu erfinden. Es geht darum, jene reibungsarmen Tools zu finden, die das Leben leichter machen – und VirtIOFS ist eines davon. Es fügt sich nahtlos in moderne Workflows ein, funktioniert mit ZFS und hilft, die unbequeme Lücke zwischen Containern und vollständiger Virtualisierung zu schließen.

Klar, perfekt ist es nicht. Es gibt ein paar Performance-Eigenheiten, und Power-User, die an die Grenzen gehen, könnten auf Bugs stoßen. Aber für die große Mehrheit der Proxmox-Setups? VirtIOFS ist genau die Art von „einfach funktionierender" Technik, von der wir alle träumen.

Kurz zusammengefasst

• VirtIOFS bietet schnelle, latenzarme Dateifreigabe zwischen Proxmox-Host und VMs
• Deutlich einfacher als Samba/NFS-Setups, mit weniger Berechtigungsärger
• Großartig für Docker-Volumes, ZFS-Dataset-Freigabe und Storage-Zugriff über mehrere VMs
• Performance liegt bei ~150 MB/s gegenüber 1,5 GB/s bei Block-Storage – für die meisten Anwendungsfälle völlig ausreichend
• Windows-Support reift noch; Linux-Gäste funktionieren am besten
• Wer nur wegen Bind-Mounts bei LXCs hängt, findet in VirtIOFS vielleicht das Ticket zu VMs