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 fast unbemerkt 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?
Kurz gesagt 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 war kein Problem, und die Performance nannte er „großartig".
Diese Erfahrung ist keine Ausnahme. Ein anderer Nutzer berichtete, er habe „sofort alles auf VirtIOFS umgestellt", als Proxmox native Unterstützung ausrollte, ohne Stolpersteine und ohne 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 und 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, ist das 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, ein einfaches und sauberes Setup, das funktioniert.
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, den 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
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"? Das kommt darauf an.
Bei rohen IOPS und Durchsatz hat VirtIO SCSI mit Block-Storage weiterhin die Nase vorn. VirtIOFS ist allerdings für den Zugriff auf Dateiebene gedacht. 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.
Ihr gesamtes Setup müssen Sie dafür nicht neu erfinden. VirtIOFS gehört zu den reibungsarmen Tools, die das Leben leichter machen. 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 ist VirtIOFS 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