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.
Bonjour,

Quel type de bridge ?

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

que donne 
rpm -qf /etc/libvirt/qemu.conf
?
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 wrote: 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.
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
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 😉 .
6 jours plus tard
Bonjour à tous,

merci à VINDICATORs et à madko.

Pour ma part, c'est résolu en grande partie.
VINDICATORs wrote: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 😉 .
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 wrote: 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
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.