Cet article est une brève introduction à virtio fs en décembre 2019.
Site officiel: https://virtio-fs.gitlab.io/
virtiofs est un nouveau système de fichiers pour le partage de répertoires entre les hôtes et les machines virtuelles invitées, développé par les ingénieurs de redhat.
Le cas d'utilisation principal consiste à utiliser virtiofs pour le système de fichiers racine des machines virtuelles légères (telles que kata-container). Il existe des avantages tels que le temps de démarrage raccourci en réduisant la copie de fichier inutile vers l'invité. Un autre cas d'utilisation consiste à masquer les détails du système de fichiers aux invités. Étant donné que l'invité ne peut pas voir les détails du système de fichiers du répertoire partagé, l'invité n'a pas à se soucier des paramètres tels que l'adresse IP et la sécurité du système de fichiers réseau.
Les systèmes de fichiers réseau tels que NFS et 9pfs existent déjà comme moyen de partager des répertoires entre les hôtes et les invités. Cependant, ils utilisent des piles / protocoles réseau et ne sont pas optimisés pour une utilisation dans des environnements virtuels (communication entre hôtes et invités sur la même machine). En outre, la sémantique du système de fichiers réseau est souvent différente de la sémantique des fichiers locaux, ce qui peut affecter le comportement de l'application (invitée).
Afin d'améliorer ces problèmes, virtiofs vise à être un système de fichiers qui (1) a des performances d'E / S élevées et (2) fournit aux invités une sémantique similaire à celle du système de fichiers local. Et pour y parvenir, le développement se fait sur la base (partiellement étendue) du protocole FUSE, qui est indépendant de la pile réseau et proche de l'interface Linux VFS [^ fuse].
[^ fuse]: FUSE a également l'avantage d'avoir de nombreuses années d'expérience.
Dans un système de fichiers FUSE normal, un démon de système de fichiers qui s'exécute dans l'espace utilisateur reçoit une requête FUSE du noyau et la traite en fonction de la requête. Dans virtiofs, un démon réside sur l'hôte (espace utilisateur), reçoit les requêtes FUSE des invités et interagit avec le système de fichiers de l'hôte si nécessaire. La communication entre l'invité et le démon se fait par virtio vhost-user ainsi que DPDK et SPDK [^ vhost].
[^ vhost]: Pour expliquer grossièrement vhost-user, le traitement de contrôle tel que l'initialisation est effectué via qemu, mais l'échange de données est effectué via qemu en utilisant virtqueue créé sur la mémoire partagée. C'est un mécanisme qui permet à l'invité et au processus dans l'espace utilisateur hôte (ici, le démon virtiofs) d'interagir sans avoir à le faire. Pour le contexte de vhost-user, par exemple, [Series] de cet article (https://www.redhat.com/en/blog/virtio-networking-first-series-finale-and-plans-2020?source = bloglisting & f% 5B0% 5D = post_tags% 3A Networking) sera utile
Pour les virtiofs, voir le [document de conception] officiel (https://virtio-fs.gitlab.io/design.html) et le forum kvm 2019 du développeur principal diapo Voir aussi / TmvA / virtio-fs-a-shared-file-system-for-virtual-machines-stefan-hajnoczi-red-hat? Iframe = no).
status La prise en charge de linux et qemu est requise pour utiliser virtiofs. Pour le moment (décembre 2019), le développement des fonctions de base est presque terminé, et la partie noyau a été fusionnée dans Linux 5.4 (cependant, la fonction DAX décrite plus loin n'est pas encore incluse). Du côté de qemu, d'autre part, le code vhost-user-fs-pci a été fusionné dans la version 4.2, mais le code du démon est actuellement en cours de révision. Si vous voulez réellement l'exécuter sous Linux + qemu, veuillez vous référer à Description du site officiel.
D'un autre côté, le support virtio fs de kata-container est déjà actif, et bien qu'il soit expérimental, virtio fs peut être utilisé à partir de la v1.7. Cela fonctionne facilement, alors je vais vous expliquer comment le faire ensuite.
Pour le moment, le moyen le plus simple d'essayer virtio fs à ce stade est d'utiliser kata-container. Assurons-nous que le répertoire partagé est réellement utilisé comme rootfs du conteneur.
Tout d'abord, installez la dernière version de kata-container à l'aide de la commande kata-deploy (les fichiers se trouvent sous / 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
Tout ce que vous avez à faire est de spécifier kata-qemu-virtiofs pour le runtime docker et virtiofs sera utilisé:
# docker run --runtime=kata-qemu-virtiofs -it busybox
Si vous vérifiez le montage à l'intérieur du conteneur, vous pouvez voir que virtiofus est utilisé pour le système de fichiers racine [^ 1]:
[^ 1]: Si vous utilisez kata-qemu pour l'exécution, vous pouvez voir que les 9pfs traditionnels sont utilisés
(En conteneur)
/ # mount -t virtio_fs (Remarque:virtio dans la version amont_C'est virtio fs au lieu de 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)
Il semble que certains fichiers de configuration soient également montés, car ils sont montés en liaison.
Si vous vérifiez le processus sur l'hôte, vous pouvez voir que le démon virtiofs (virtiofsd) est en cours d'exécution:
(En hôte)
$ 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
Le répertoire spécifié ici comme source sera le répertoire partagé utilisé par virtiofs.
Assurez-vous que l'hôte et l'invité partagent réellement le répertoire.
Tout d'abord, examinons le répertoire spécifié comme source sur l'hôte:
(En hôte)
# 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
Vous pouvez voir qu'il y a des fichiers de configuration directement sous le répertoire partagé et rootfs sous le répertoire avec un autre ID de conteneur [^ 2].
[^ 2]: La raison pour laquelle l'invité ne voit pas la zone directement sous le répertoire partagé est probablement parce qu'il s'agit de pivot_root.
Le contenu de ce répertoire étant partagé avec l'invité, vous pouvez confirmer que le contenu peut être lu à partir de l'hôte lorsque vous créez réellement un fichier approprié dans l'invité.
(En conteneur)
/ # echo abc > XXX
/ # ls
XXX bin dev etc home mnt proc root sys tmp usr var
(En hôte)
# 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
Au contraire, si vous créez un fichier depuis l'hôte, vous pouvez le lire depuis l'invité.
L'un des objectifs de virtiofs est d'obtenir des performances d'E / S élevées, et l'une des fonctionnalités pour cela est DAX. DAX est une abréviation de Direct Access et est un terme souvent utilisé dans le contexte de la mémoire non volatile [^ dax]. Cependant, virtiofs DAX n'a rien à voir avec la mémoire non volatile réelle, permettant aux invités d'accéder à la mémoire de l'hôte sans utiliser le cache de page de l'invité = (plusieurs) invités et hôtes partagent la mémoire hôte (cache de page), est ce que cela signifie. Les performances sont améliorées car il n'y a pas de communication invité-hôte lorsque les données sont en mémoire. Le partage du cache de page présente également l'avantage que les modifications de données sont instantanément visibles pour les autres invités / hôtes (similaire à la sémantique des fichiers locaux) et réduit l'utilisation de la mémoire.
[^ dax]: accéder directement à l'appareil sans utiliser le cache de page
Je vais expliquer brièvement le mécanisme de DAX. Tout d'abord, pour utiliser virtio, vous devez ajouter un périphérique virtio au début de qemu, qui est reconnu comme PCI par l'invité [^ vhost-user-fs]. Et PCI a un registre de contrôle appelé BAR qui indique la zone mémoire de l'appareil. La fonction de DAX est réalisée en accédant à la zone mémoire visible depuis cette BARRE en mappant les données [^ aaa]. Bien sûr, la taille de la zone est limitée, donc virtiofs contrôle quelles données sont mappées / non mappées où dans l'espace BAR (appelé fenêtre DAX). Un protocole FUSE a également été ajouté à cet effet pour demander des zones à mapper / démapper.
[^ vhost-user-fs]: virtiofs reconnaît que virtiofs est disponible pour les invités en ajoutant un périphérique appelé vhost-user-fs-pci aux options de démarrage de qemu. [^ aaa]: Puisque cette zone ressemble à un périphérique non volatile pour l'invité, le code du noyau utilise le code DAX.
Notez que virtiofs fusionné dans le noyau 5.4 n'a pas encore de fonctionnalités de support DAX, donc si vous voulez essayer cette fonctionnalité, vous pouvez soit la compiler vous-même en utilisant la branche de développement, soit utiliser kata-container (kata). -Déjà inclus dans la version conteneur de virtiofs).
Le démon virtiofs (virtiofsd) qui sera fusionné dans qemu est implémenté en C, mais bien sûr d'autres implémentations sont possibles. En fait, rust (crosvm) a également implémenté un démon [^ crosvm]. De plus, je n'ai pas trouvé beaucoup d'informations détaillées, mais il semble que certaines personnes réfléchissent déjà à la façon d'utiliser virtiofs et SPDK en combinaison [^ snia]. Depuis que le code a été fusionné en amont, je pense que le nombre de cas d'utilisation de virtiofus augmentera l'année prochaine.
Recommended Posts