Fedora-Fr - Communauté francophone Fedora - Linux

Communauté francophone des utilisateurs de la distribution Linux Fedora.

  

Dernière news : Venez tester Fedora 30 Beta !

#1 06/12/2018 17:03:21

alexandre01
Membre
Inscription : 06/05/2018
Messages : 8

problème avec interface tap

Bonjour,

je n'arrive pas à faire fonctionner une interface tap0 derrière un bridge, par exemple br0

En effet, quand je lance qemu, j'ai toujours une erreur:

qemu-system-x86_64: could not open /dev/net/tun: Permission denied

Malgré le temps passé et les solutions écumées, je ne sais plus quoi faire.

Si quelqu'un a une idée, je le remercie.

Hors ligne

#2 06/12/2018 19:09:59

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 6 805
Site Web

Re : problème avec interface tap

Bonjour,

Quel type de bridge ?

Peux-tu nous donner la définition de la VM ?

que donne

rpm -qf /etc/libvirt/qemu.conf

?

Hors ligne

#3 07/12/2018 00:26:49

alexandre01
Membre
Inscription : 06/05/2018
Messages : 8

Re : problème avec interface tap

bonjour madko,


je te remercie de ta réponse.

Quel type de bridge ?

Un bridge virtuel, lié à une interface tap, avec les commandes suivantes, sachant que je n'utilise pas encore virt-manager.

Pour l'interface tap:

sudo ip tuntap add dev tap0 mode tap group kvm (ou user alexandre)
sudo ip link set tap0 up promisc on

pour le bridge:

sudo ip link add br0 type bridge
sudo ip link set br0 up
ip link set tap0 master br0
ip addr add 192.168.1.0/24 dev br0

Ensuite, j'ajoute br0 dans /etc/qemu/bridge.conf

allow br0

Puis:

systemctl restart NetworkManager

Puis je tape les commandes de qemu-kvm:

 qemu-system-x86_64 [...] -M q35 [...] -cpu host -bios OVMF-pure-efi.fd  [...] -drive file=debian_stretch.qcow2,cache=none,if=virtio,media=disk,index=0 -boot order=cd,once=d,menu=on,strict=on [...] -enable-kvm -netdev tap,ifname=tap0,id=debiannetwork,script=no,downscript=no -device virtio-net-pci,netdev=debiannetwork
 [...] && remote-viewer spice+unix:///tmp/spice.sock

Après, je peux donner la définition complète, mais elle fait 8 lignes sous gedit.



Je ne pense pas que le problème provient de la création de l'interface tap0 ni de br0, le problème provient des droits de:

 /dev/net/tun

A ce jour, je ne trouve pas de solution, en changeant de groupe, en m'ajoutant en tant que propriétaire avec chown, je ne sais pas quoi faire.

D'autant plus que la contrainte supplémentaire est l'utilisation d'un VPN, qui cohabite avec /dev/net/tun.

madko a écrit :

que donne

rpm -qf /etc/libvirt/qemu.conf

?


La résultat de la commande demandée est:

libvirt-daemon-driver-qemu-4.7.0-1.fc29.x86_64

Je n'utilise pas virt-manager aujourd'hui, car je n'ai rien compris lors de mes premières utilisations.
Maintenant je comprends mieux, mais pas toutes les options.


Je te remercie.

Hors ligne

#4 07/12/2018 08:21:29

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 6 805
Site Web

Re : problème avec interface tap

Ok donc il s'agit d'un bridge natif (comparé à d'autres solutions de bridge comme OpenVswitch par ex)

Quels sont les droits sur /dev/net/tun ?

ll /dev/net/tun

La seule fois où j'ai eu cette erreur je passais par libvirt, qui est quand même bien plus simple (définition de la VM en XML pour éviter les 8 lignes de commandes qemu etc). Donc je sais pas si ça te concerne mais ça pourrait être une piste. Dans le fichier /etc/libvirt/qemu.conf il y a un bloc:

#cgroup_device_acl = [
#    "/dev/null", "/dev/full", "/dev/zero",
#    "/dev/random", "/dev/urandom",
#    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
#    "/dev/rtc","/dev/hpet", "/dev/sev"
#]

Qui est commenté mais nous indique les valeurs par défaut. Je devais décommenter ça, et ajouter /dev/net/tun dans la liste. Puis relancer le service libvirt. Comment ça se concrêtise pour ton cas ?? Il faudrait trouver le moyen de voir les ACL des cgroup

Hors ligne

#5 07/12/2018 08:41:49

VINDICATORs
RédactWikix and the graphicatorix!
Modérateur
Lieu : Toulouse(31) France
Inscription : 23/11/2004
Messages : 17 440
Site Web

Re : problème avec interface tap

Pour info virt-manager c'est une interface graphique qui se base sur libvirt (incluant QEMU, KVM, ...)

Libvirt c'est ce qui gère la virtualisation derrière :
https://fr.wikipedia.org/wiki/Libvirt

Il ne faut pas confondre wink .


AMD Ryzen 7 2700X + MSI Gaming Pro Carbon X470, 32Go de RAM DDR4 3000@3133Mhz Gskill Ageia C16, AMD Radeon RX590 Sapphire Nitro+ Special Edition 8Go GDDR5
SSD Samsung : 1x 970 NVME (PCI-express 3.0x4) 500Go + 1x 850 EVO 250Go + 2x 860 EVO 500Go / HDD : 1x2To WD black 64Mo + 1x4to WD Black 128Mo + 3To WD red
Boitier GMT Bequiet Dark 900 + Lepa 800W 80+gold

Hors ligne

#6 12/12/2018 21:33:32

alexandre01
Membre
Inscription : 06/05/2018
Messages : 8

Re : problème avec interface tap

Bonjour à tous,

merci à VINDICATORs et à madko.

Pour ma part, c'est résolu en grande partie.

VINDICATORs a écrit :

Pour info virt-manager c'est une interface graphique qui se base sur libvirt (incluant QEMU, KVM, ...)

Libvirt c'est ce qui gère la virtualisation derrière :
https://fr.wikipedia.org/wiki/Libvirt

Il ne faut pas confondre wink .

Merci du renseignement, je me suis mal exprimé, en effet, je pensais au fait quand j'utilisais virt-manager pour configurer le réseau, et dont le réseau hôte était "désactivé" et que l'IPV6 ne fonctionnait pas, d'où l'impossibilité d'installer une distribution sans désactiver l'ipv6 avant l'installation.
Par contre les machines qemu-kvm créées en ligne de commandes ne sont pas reconnues par libvirt.

 

madko a écrit :

Ok donc il s'agit d'un bridge natif (comparé à d'autres solutions de bridge comme OpenVswitch par ex)

Quels sont les droits sur /dev/net/tun ?

ll /dev/net/tun

La seule fois où j'ai eu cette erreur je passais par libvirt, qui est quand même bien plus simple (définition de la VM en XML pour éviter les 8 lignes de commandes qemu etc). Donc je sais pas si ça te concerne mais ça pourrait être une piste. Dans le fichier /etc/libvirt/qemu.conf il y a un bloc:

#cgroup_device_acl = [
#    "/dev/null", "/dev/full", "/dev/zero",
#    "/dev/random", "/dev/urandom",
#    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
#    "/dev/rtc","/dev/hpet", "/dev/sev"
#]

Qui est commenté mais nous indique les valeurs par défaut. Je devais décommenter ça, et ajouter /dev/net/tun dans la liste. Puis relancer le service libvirt. Comment ça se concrêtise pour ton cas ?? Il faudrait trouver le moyen de voir les ACL des cgroup

Cela ne donnait rien, sachant que les machines créées à la main ne sont pas gérées par libvirt.

Et j'avais lu que le mode tap n'était pas possible à cause d'histoire de sécurité, donc j'ai essayé de tester  macvtap, mais... ca semble être utilisé pour de grand domaines, et la documentation est ... n'y a t'il pas de centralisation de documentation à jour ? C'est un véritable problème concernant les distributions GNU\Linux.

Je suis reparti sur tap, sachant que j'ai constaté une anomalie.

En effet, en tapant:

sudo ip tuntap add dev tap0 mode tap user 1000

Je n'ai plus le message d'erreur suivant:

qemu-system-x86_64: could not open /dev/net/tun: Permission denied

et je peux lancer un invité  via qemu-kvm  avec tap situé dans /dev/tapX sans message d'erreur, et sans être root.

qemu-system-x86_64 [...] -M q35 [...] -cpu host -bios OVMF-pure-efi.fd  [...] -drive file=debian_stretch.qcow2,cache=none,if=virtio,media=disk,index=0 -boot order=cd,once=d,menu=on,strict=on [...] -enable-kvm -netdev tap,ifname=/dev/tap5,id=debiannetwork,script=no,downscript=no -device virtio-net-pci,netdev=debiannetwork

Par contre, pas de connexion dans l'invité.

De plus, lors d'une manipulation (création d'un bridge situé dans le même réseau que celui de l'hôte (même plage d'adresses IP avec le même masque), pour constater si cela fonctionnait (car même "domaine" réseau, j'avais constaté que l'invité fonctionnait et pouvait communiquer avec l'hôte, avec un inconvénient, le réseau hôte ne fonctionnait pas, et "ca casse" NetworkManager (il faut redémarrer), sachant que l'interface enp2s0 était activée dans l'hôte et donc causait le problème).

Donc création d' un script en créant un fichier ifconfig-br0, afin de créer un bridge br0 dans:

/etc/sysconfig/network-scripts/ifcfg-br0

en ajoutant ceci:

DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge

Puis en modifiant le script concernant le réseau filaire en fonctionnement:

nano /etc/sysconfig/network-scripts/ifcfg-enp2s0

j'ai fait les modifications suivantes:

HWADDR=XX:XX:XX:XX:XX:XX
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
#je désactive la ligne ci-dessous car je ne veux pas que cette connexion se lance au démarrage, juste le bridge br0, sinon tout est cassé.
#BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp2s0
UUID=da0c1734-d1ea-49b6-850e-a8337b3ff6d3
ONBOOT=yes
MACADDR=00:00:00:00:00:01
#J'ajoute la ligne ci-dessous pour lier l'interface réseau actuelle au bridge ci-dessous br0
BRIDGE=br0

On ajoute dans le fichier /etc/sysctl.conf

net.ipv4.ip_forward = 1
net.ipv4.conf.default.arp_filter = 1

et on valide les changements par:

 sysctl -p /etc/sysctl.conf

Ci-dessous, je ne sais pas si cela est utile, parce que je ne sais pas si c'est lié à libvirtd et que cela joue sur les machines créées par qemu-kvm en ligne de commandes (il me semble que oui, mais la flemme de vérifier) je rajoute:

 allow br0

dans le fichier /etc/qemu/bridge.conf

On redémarre,

Et en ligne de commande:

qemu-system-x86_64 [...] -M q35 [...] -cpu host -bios OVMF-pure-efi.fd  [...] -drive file=debian_stretch.qcow2,cache=none,if=virtio,media=disk,index=0 -boot order=cd,once=d,menu=on,strict=on [...] -enable-kvm -netdev bridge,br=br0,id=debiannetwork -device virtio-net-pci,netdev=debiannetwork
 [...] && remote-viewer spice+unix:///tmp/spice.sock

ne pas oublier d'installer spice-vdagent pour profiter de la paravirtualisation, et quemu-guest-agent pour ...? les ports séries?

Lors du lancement de l'invité, une interface tap est créée et une adresse IP est assignée dans l'invité, j'ai bien accès à l'interface "enp2s0",et la machine invitée peut communiquer avec l'hôte (on peut pinger etc.)

Compatible avec virtualbox.

edit: On peut faire tourner plusieurs machines invitées derrière le même bridge.
Par contre, pour ne pas avoir des machines avec la même adresse IP, le même masque réseau et la même adresse MAC, il faut attribuer une adresse MAC différente pour différencier le réseau de chaque machine, il faut donc ajouter une adresse MAC personnalisée pour chaque machine via qemu:

-netdev bridge,br=br0,id=fedora29network -device virtio-net-pci,netdev=fedora29network,mac=00:32:02:50:13:5e

Je vous remercie de vos réponses.
Cordialement

Dernière modification par alexandre01 (13/12/2018 03:01:44)

Hors ligne

#7 13/12/2018 20:02:56

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 6 805
Site Web

Re : problème avec interface tap

Il faut vraiment que tu regarde du côté de la libvirt. Tu te complique la vie pour pas grand chose. La gestion des bridges, réseaux, disques etc ainsi que la génération d'adresse MAC y sont traités. C'est de la ligne de commande, c'est moins risqué que de géré des lignes qemu de 15km de long, et gros avantage c'est agnostique de la techno sous jacente.

La configuration d'une VM se fait via XML et c'est bien plus lisible:

<domain type='kvm' id='128'>
  <name>VM</name>
  <memory unit='KiB'>2097152</memory>
  <vcpu placement='auto'>1</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
    <boot dev='network'/>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/datastore/VM-disk0'/>
      <target dev='sda' bus='virtio'/>
      <alias name='virtio-disk0'/>
    </disk>
    <interface type='bridge'>
      <source bridge='br0'/>
      <vlan>
        <tag id='0'/>
      </vlan>
      <virtualport type='openvswitch'/>
      <target dev='tap2651'/>
      <model type='virtio'/>
      <alias name='net0'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='5954' autoport='yes' keymap='fr'>
      <listen type='address'/>
    </graphics>
    <video>
      <model type='cirrus' vram='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
    </video>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
    </memballoon>
  </devices>
</domain>

Enfin, c'est aussi un poil plus sérieux de faire ça avec une CentOS7 par ex, pour facilement enlever networkmanager par ex. Ajouter un cycle de vie de 6 mois sur ce genre de projet c'est aussi se compliquer la vie.

Sinon, pour de meilleur perf, et si tu veux isoler les réseaux de tes VM, je te suggère de regarder du côté d'OpenVswitch. C'est aussi géré par la libvirt.

Hors ligne

Pied de page des forums