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