Forum général.général Lecteur réseau dans guest qemu windows dans host linux: samba ou nfs ?

Posté par  . Licence CC By‑SA.
Étiquettes :
2
14
fév.
2023

Bonjour,

Titre cryptique pour question potentiellement capillotractée.

J'ai une VM qemu windows tournant sur une machine linux en mode bridge.
Cette VM doit communiquer avec un NAS.

Quelle est la solution la plus efficace ?

  • 1/ exposer le NAS via samba et déclarer un lecteur réseau directement vers le NAS dans la VM
    • NAS<-samba->(hôte)<->VM
  • 2/ exposer le NAS via NFS, activer la gestion de NFS dans windows et déclarer un lecteur réseau NFS dans la VM (jamais fait, mais cela semble être possible avec du win11 pro, quoique les performances semblent ne pas être au top)
    • NAS<-nfs->(hôte)<->VM
  • 3/ exposer le NAS via NFS, mounter le NAS via NFS dans l’hôte linux, exposer le dossier de l’hôte linux via samba et déclarer un lecteur réseau samba vers l’hôte dans la VM
    • NAS<-nfs->hôte<-samba->VM
  • 4/ comme 3/ mais en utilisant du NFS dans la VM à la place de samba
    • NAS<-nfs->hôte<-nfs->VM
  • 5/ toute autre solution encore plus tordue du moment que cela fonctionne

Mon idée est de laisser le moins possible la main à la machine virtuelle en ce qui concerne les accès réseau de manière à pouvoir laisser l’hôte gérer les accès au NAS.

Au doigt mouillé, je pencherai pour la 3/, mais je n'ai aucune idée de l'impact de cette double interface nfs/samba en termes de performance réseau.
Bien évidemment la 1/ semble la solution la plus directe, mais rend la VM dépendante de l'environnement réseau, alors que la 3 permet de tout paramétrer sur l’hôte.

Bref, si une personne parmi vous avait déjà joué avec cette configuration, je suis preneur de vos conseils avisés.

Merci

  • # mais pourquoi ????

    Posté par  . Évalué à 6.

    Mon idée est de laisser le moins possible la main à la machine virtuelle en ce qui concerne les accès réseau de manière à pouvoir laisser l’hôte gérer les accès au NAS.

    si tu veux limiter l'acces de ta VM à ton reseau, il ne faut pas la mettre en BRIDGE sur ton reseau, mais la mettre en NAT

    ainsi c'est ta machine HOTE qui fera la bascule de reseau entre l'interieur (les VMs) et l'exterieur (ton reseau)

    tu pourras alors mettre un parefeu qui limitera les actions

    par contre si tu veux de la performance, alors il faut en effet mettre la VM en bridge,
    et configuré correctement les droits sur le NAS.

    si la VM est un windows, utiliser les protocoles connus de windows (SMB ou CIFS)
    si la VM est un linux/unix, etc, utiliser NFS

  • # NAS<-nfs->Hôte . Tout simplement.

    Posté par  . Évalué à 4.

    Comme l'a souligné NeoX, c'est une très mauvaise idée d'utiliser le mode bridge si on veut restreindre les accès réseau de la VM.

    Le montage sera très simple et se limitera à NAS<-nfs->Hôte avec les bonnes options.

    Bon, c'est très simplifié en fait. Voici les détails techniques.

    Le scénario préconisé est en fait un variant de la solution 3, mais avec l'option spéciale smb de QEMU qui permet de ne pas se farcir la configuration de SAMBA côté hôte pour monter le dossier partagé de la VM.

    Le wiki de Arch Linux et la doc de QEMU détaillent l'utilisation de cette option, avec la configuration réseau côté VM.

  • # Cf Virtualbox

    Posté par  . Évalué à 4. Dernière modification le 14 février 2023 à 23:13.

    Virtualbox permet de partager un emplacement de l'hôte (qu'il soit local ou NFS) avec une VM, via un partage SMB géré par VirtualBox directement. Et ça fonctionne même si la VM n'a pas de carte réseau.

    Joie, on dirait que tu peux faire la même chose avec qemu.

    J'utilise cette méthode (VM Windows sans carte réseau) dans ces deux situations :

    • Pour le logiciel BNC Express, qui fonctionne bien sur Wine mais pas à 100%.
    • Pour pouvoir utiliser Acrobat Reader sur des formulaires d'immigration de l'administration québecoise, qui comportent des formulaires XFA et des scripts qui ne fonctionnent QUE dans Acrobat.

    (edit: en fait je dis la même chose que volts, désolé !)

  • # merci

    Posté par  . Évalué à 2.

    Merci à vous trois pour vos réponses !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.