Dieser Artikel ist eine kurze Einführung in virtio fs ab Dezember 2019.
Offizielle Website: https://virtio-fs.gitlab.io/
virtiofs ist ein neues Dateisystem für die gemeinsame Nutzung von Verzeichnissen zwischen Hosts und Gast-VMs, das von Redhat-Ingenieuren entwickelt wurde.
Der Hauptanwendungsfall besteht darin, Virtiofs für das Root-Dateisystem von Lightweight-VMs (z. B. Kata-Container) zu verwenden. Es gibt Vorteile wie eine verkürzte Startzeit, indem unnötige Dateikopien auf den Gast reduziert werden. Ein weiterer Anwendungsfall besteht darin, Dateisystemdetails vor Gästen zu verbergen. Da der Gast die Details des Dateisystems des freigegebenen Verzeichnisses nicht sehen kann, muss er sich beispielsweise nicht um die IP- und Sicherheitseinstellungen des Netzwerkdateisystems kümmern.
Netzwerkdateisysteme wie NFS und 9pfs sind bereits vorhanden, um Verzeichnisse zwischen Hosts und Gästen gemeinsam zu nutzen. Sie verwenden jedoch Netzwerkstapel / -protokolle und sind nicht für die Verwendung in virtuellen Umgebungen (Kommunikation zwischen Hosts und Gästen auf demselben Computer) optimiert. Außerdem unterscheidet sich die Semantik des Netzwerkdateisystems häufig von der lokalen Dateisemantik, was sich auf das Verhalten der (Gast-) Anwendung auswirken kann.
Um diese Probleme zu verbessern, soll virtiofs ein Dateisystem sein, das (1) eine hohe E / A-Leistung aufweist und (2) Gästen eine Semantik bietet, die dem lokalen Dateisystem ähnlich ist. Um dies zu erreichen, wird die Entwicklung auf der Grundlage des (teilweise erweiterten) FUSE-Protokolls durchgeführt, das netzwerkstapelunabhängig ist und sich in der Nähe der Linux-VFS-Schnittstelle befindet [^ fuse].
[^ fuse]: FUSE hat auch den Vorteil langjähriger Erfahrung.
In einem normalen FUSE-Dateisystem empfängt ein Dateisystem-Daemon, der im Benutzerbereich ausgeführt wird, eine FUSE-Anforderung vom Kernel und verarbeitet sie gemäß der Anforderung. In virtiofs befindet sich ein Daemon auf dem Host (Benutzerbereich), empfängt FUSE-Anforderungen von Gästen und interagiert bei Bedarf mit dem Dateisystem des Hosts. Die Kommunikation zwischen dem Gast und dem Daemon erfolgt durch virtio vhost-user sowie DPDK und SPDK [^ vhost].
[^ vhost]: Um vhost-user grob zu erklären, wird die Steuerungsverarbeitung wie die Initialisierung über qemu ausgeführt, der Datenaustausch erfolgt jedoch über qemu unter Verwendung der im gemeinsam genutzten Speicher erstellten Virtqueue. Es ist ein Mechanismus, mit dem der Gast und der Prozess im Host-Benutzerbereich (hier der virtiofs-Daemon) interagieren können, ohne dass dies erforderlich ist. Für den Hintergrund von vhost-user beispielsweise [Serie](https://www.redhat.com/de/blog/virtio-networking-first-series-finale-and-plans-2020?source] dieses Artikels. = Bloglisting & f% 5B0% 5D = post_tags% 3A Networking) wird hilfreich sein
Informationen zu den Vorteilen finden Sie im offiziellen Designdokument und im KVM-Forum 2019 des Hauptentwicklers Folie. Siehe auch / TmvA / virtio-fs-a-shared-file-system-für-virtuelle-maschinen-stefan-hajnoczi-red-hat? Iframe = no).
status Unterstützung für Linux und Qemu ist erforderlich, um Virtiofs zu verwenden. Derzeit (Dezember 2019) ist die Entwicklung der Grundfunktionen fast abgeschlossen, und der Kernel-Teil wurde in Linux 5.4 zusammengeführt (die später beschriebene DAX-Funktion ist jedoch noch nicht enthalten). Auf der qemu-Seite wurde der vhost-user-fs-pci-Code in 4.2 zusammengeführt, aber der Daemon-Code wird derzeit überprüft. Wenn Sie es tatsächlich unter Linux + qemu ausführen möchten, lesen Sie bitte Erläuterung der offiziellen Website.
Andererseits ist die virtio fs-Unterstützung von kata-container bereits aktiv, und obwohl sie experimentell ist, können virtio fs ab Version 1.7 verwendet werden. Es funktioniert leicht, also werde ich erklären, wie es als nächstes geht.
Derzeit ist die Verwendung von Kata-Containern der einfachste Weg, Virtio fs zu testen. Stellen wir sicher, dass das freigegebene Verzeichnis tatsächlich als Rootfs des Containers verwendet wird.
Installieren Sie zunächst die neueste Version von kata-container mit dem Befehl kata-deploy (Dateien befinden sich unter / opt / kata):
# docker run --runtime=runc -v /opt/kata:/opt/kata -v /var/run/dbus:/var/run/dbus -v /run/systemd:/run/systemd -v /etc/docker:/etc/docker -it katadocker/kata-deploy kata-deploy-docker install
Alles, was Sie tun müssen, ist, kata-qemu-virtiofs für die Docker-Laufzeit anzugeben, und virtiofs werden verwendet:
# docker run --runtime=kata-qemu-virtiofs -it busybox
Wenn Sie den Mount im Container überprüfen, können Sie sehen, dass virtiofus für das Root-Dateisystem verwendet wird [^ 1]:
[^ 1]: Wenn Sie zur Laufzeit kata-qemu verwenden, können Sie sehen, dass die traditionellen 9pfs verwendet werden
(Im Container)
/ # mount -t virtio_fs (Hinweis:virtio in der Upstream-Version_Es ist virtio fs statt fs)
kataShared on / type virtio_fs (rw,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,dax)
kataShared on /etc/resolv.conf type virtio_fs (rw,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,dax)
kataShared on /etc/hostname type virtio_fs (rw,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,dax)
kataShared on /etc/hosts type virtio_fs (rw,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,dax)
Es sieht so aus, als wären einige Konfigurationsdateien ebenfalls gemountet, da sie gebunden gemountet sind.
Wenn Sie den Prozess auf dem Host überprüfen, können Sie feststellen, dass der virtiofs-Daemon (virtiofsd) ausgeführt wird:
(Im Host)
$ pgrep -a virtiofsd
13154 /opt/kata/bin/virtiofsd --fd=3 -o source=/run/kata-containers/shared/sandboxes/<container ID> -o cache=always --syslog -o no_posix_lock -f
Das hier als Quelle angegebene Verzeichnis ist das von virtiofs verwendete freigegebene Verzeichnis.
Stellen Sie sicher, dass Host und Gast das Verzeichnis tatsächlich gemeinsam nutzen.
Schauen wir uns zunächst das als Quelle auf dem Host angegebene Verzeichnis an:
(Im Host)
# ls /run/kata-containers/shared/sandboxes/<container ID>
<container ID>
<container ID>-resolv.conf
<container ID>-hosts
<container ID>-hostname
# ls /run/kata-containers/shared/sandboxes/<container ID>/<container ID>
rootfs
# ls /run/kata-containers/shared/sandboxes/<container ID>/<container ID>/rootfs
bin dev etc home mnt proc root sys tmp usr var
Sie können sehen, dass sich einige Konfigurationsdateien direkt unter dem freigegebenen Verzeichnis und rootfs unter dem Verzeichnis mit einer anderen Container-ID befinden [^ 2].
[^ 2]: Der Grund, warum der Gast den Bereich direkt unter dem freigegebenen Verzeichnis nicht sieht, ist wahrscheinlich, dass es sich um pivot_root handelt.
Da der Inhalt dieses Verzeichnisses für den Gast freigegeben wird, können Sie bestätigen, dass der Inhalt vom Host gelesen werden kann, wenn Sie tatsächlich eine entsprechende Datei im Gast erstellen.
(Im Container)
/ # echo abc > XXX
/ # ls
XXX bin dev etc home mnt proc root sys tmp usr var
(Im Host)
# ls /run/kata-containers/shared/sandboxes/<container ID>/<container ID>/rootfs
XXX bin dev etc home mnt proc root sys tmp usr var
# cat /run/kata-containers/shared/sandboxes/<container ID>/<container ID>/rootfs/XXX
abc
Wenn Sie dagegen eine Datei vom Host aus erstellen, können Sie sie vom Gast lesen.
Eines der Ziele von virtiofs ist es, eine hohe E / A-Leistung zu erzielen, und eines der Merkmale hierfür ist DAX. DAX ist eine Abkürzung für Direct Access und ein Begriff, der häufig im Zusammenhang mit nichtflüchtigem Speicher verwendet wird [^ dax]. Virtiofus DAX ist jedoch für den tatsächlichen nichtflüchtigen Speicher irrelevant, sodass Gäste auf den Hostspeicher zugreifen können, ohne den Seitencache des Gastes zu verwenden = (mehrere) Gäste und Hosts teilen sich den Hostspeicher (Seitencache). ist was es bedeutet. Die Leistung wird verbessert, da keine Gast-Host-Kommunikation stattfindet, wenn sich die Daten im Speicher befinden. Das Freigeben des Seitencaches hat auch den Vorteil, dass Datenänderungen für andere Gäste / Hosts sofort sichtbar sind (ähnlich der lokalen Dateisemantik) und die Speichernutzung reduziert.
[^ dax]: Direkter Zugriff auf das Gerät ohne Verwendung des Seitencaches
Ich werde kurz den Mechanismus von DAX erklären. Um virtio verwenden zu können, müssen Sie zunächst das virtio-Gerät zum Zeitpunkt des Starts von qemu hinzufügen, das vom Gast [^ vhost-user-fs] als PCI erkannt wird. Und PCI hat ein Steuerregister namens BAR, das den Speicherbereich des Geräts anzeigt. Die Funktion von DAX wird durch Zugriff auf den von dieser BAR aus sichtbaren Speicherbereich durch Zuordnung der Daten [^ aaa] realisiert. Natürlich ist die Größe des Bereichs begrenzt, sodass virtiofs steuert, welche Daten wo im BAR-Bereich (als DAX-Fenster bezeichnet) zugeordnet / nicht zugeordnet werden. Zu diesem Zweck wurde auch ein FUSE-Protokoll hinzugefügt, um Bereiche zum Zuordnen / Aufheben der Zuordnung aufzufordern.
[^ vhost-user-fs]: virtiofs erkennt, dass virtiofs für Gäste verfügbar ist, indem ein Gerät namens vhost-user-fs-pci zu den Startoptionen von qemu hinzugefügt wird. [^ aaa]: Da dieser Bereich für den Gast wie ein nichtflüchtiges Gerät aussieht, verwendet der Kernel-Code den DAX-Code.
Beachten Sie, dass in Kernel 5.4 zusammengeführte Virtiofs noch keine DAX-Unterstützungsfunktionen haben. Wenn Sie diese Funktion ausprobieren möchten, können Sie sie entweder selbst über den Entwicklungszweig kompilieren oder Kata-Container (Kata) verwenden. - Bereits in der Containerversion von virtiofs enthalten).
Der virtiofs-Daemon (virtiofsd), der in qemu zusammengeführt wird, ist in C implementiert, aber natürlich sind auch andere Implementierungen möglich. Tatsächlich hat rust (crosvm) auch einen Daemon [^ crosvm] implementiert. Ich konnte auch nicht viele detaillierte Informationen finden, aber es scheint, dass einige Leute bereits darüber nachdenken, wie man Virtiofs und SPDK in Kombination verwendet [^ snia]. Da der Code vorgelagert zusammengeführt wurde, denke ich, dass die Anzahl der Fälle, in denen virtiofus verwendet wird, im nächsten Jahr zunehmen wird.
Recommended Posts