Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

QEMU/KVM Connexion par pont

didierg

Bonjour,
J’utilisais Innotek/Sun/Oracle VirtualBox depuis presque une vingtaine d’années (2006 de mémoire) mais à force de lire sur ce forum qu’il y avait la solution QEMU/KVM intégrée j’ai fini par installer Virtual Machine Manager et je me suis lancé.
Pas de problème pour créer sur mon host Fedora 43 un guest Fedora 43 lui aussi, c’est simple et ça fonctionne.
Où ça se complique, c’est que je ne veux pas que le réseau soit connecté en NAT mais en Bridge pour pouvoir accéder à ma VM à partir de mon host et à partir d’autres VM.
J’ai trouvé plein de documentations et tutoriels mais rien de simple, ça me parait très compliqué par rapport à VirtualBox où il suffisait de trois clics de souris pour passer en Bridge et où il n’y avait aucune configuration à faire sur le host.
Est-ce moi qui n’est pas tout compris ou est-ce réellement si complexe ?
Merci pour vos lumières.

didierg

Quid du package bridge-utils qui existe pour Fedora 43 et auquel font référence plusieurs documentations ?
Sur Koji je vois:

The bridge-utils package is deprecated, the bridge command from the iproute package should preferably be used for linux ethernet bridges.

xylphute

Le bridge dans virt manager fonctionne très bien, je ne rencontre pas de problème particulier. Tu peux détailler ce qui te bloque ?

Si c’est ce que je pense il faut un nom de périphérique pour l’utiliser qui est virbr0.

C’est sûr, qemu ce n’est pas si userfriendly que virtualbox, mais c’est tellement plus puissant. Le gui virtmanager aide grandement et permet de tout faire.

Je dirais que oui c’est un peu plus complexe, plus complet, qu’il faut se détacher de la logique de virtualbox (un peu comme un utilisateur windows qui se met a linux) et qu’il y a une part de “tu ne comprends pas tout” 😉. Après il faut bien entendu garder la logique de base sur l’allocation des ressources pour créer la VM. Mais ça tu le sais déjà puisque tu virtualise déjà un système.

Ps: pas souvenir d’avoir installé bridge-utils.

VINDICATORs

Perso j’utilise surtout le mode open :
https://doc.fedora-fr.org/wiki/Infrastructure_KVM/QEMU%2BKubernetes%2BCEPH#Configuration_R%C3%A9seaux_:

Mais cela implique aussi de rajouter les routes si l’on veut pouvoir relier le réseau sur d’autres machines/périphériques physique en les ajoutant dessus.

Après j’en ai déjà parlé ailleurs. Dsl si cela fait doublon 😛.

A voir si ce serait utile de rajouter cette partie à la doc : https://doc.fedora-fr.org/wiki/Virtualisation_:_KVM,_Qemu,_libvirt_en_images

xylphute

Oui il faut mettre à jour l’étape 5. Dedans ça dit qu’en bridge il faut une carte réseau libre ce qui n’est pas/plus vrai.

Je le detaille dans la Doc pour le monogpu passthrough, il existe une carte réseau virtuelle virbr0 prévu pour ça.

didierg

En regardant bien, je ne pense pas que QEMU/KVM soit adapté à mon usage occasionnel de la virtualisation.
Je ne cherche pas à avoir une ou des machines virtuelles actives en permanence mais juste à pouvoir démarrer une machine virtuelle en cas de besoin sans réel soucis de performances.

xylphute

didierg qemu/kvm répond parfaitement à ton besoin. Sinon tu penses utiliser quoi? Virtualbox et son manque cruel de fiabilité ?

Ça m’arrive de faire de la VM occasionnelle et ça le fait carrément.

Sinon tu as essayé de nouveau pour le bridge?

fgland

C’est mon cas d’utilisation des VM et QEMU/KVM fait très bien l’affaire.

VINDICATORs

fgland

J’ai des Vm de tests à la demande, des vm de test plus spécialisés, des vm permanente, des vm qui peuvent faire le café…

Rien que l’an dernier au capitole du libre je me suis créé une VM avec Haiku suite aux discutions avec le stand voisin en deux deux 😛. Et j’en avais 10 de lancé en // si les gens voulaient voir tester les versions de Fedora… Et pourtant sur mon vieux pc portable.

nouvo09

VINDICATORs
Ne confonds quand même pas ton niveau de compétence avec celui d’un utilisateur moyen.

VINDICATORs

nouvo09

J’étais débutant dans le domaine quand j’ai commencé à apprécier les possibilités de QEMU/KVM 😉.

J’ai juste atteint les limites de virtualbox trop vite après la première fois où j’ai créé 3 VM en même temps… Du moins à l’époque. Et non perso je dénigre pas virtualbox, juste que j’ai plus galéré quand même…

Et puis bon… Avec “machine” ou “virt-manager” c’est vrai que c’est si compliqué…

nouvo09

xylphute Virtualbox et son manque cruel de fiabilité ?

Le dénigrement n’apporte rien au raisonnement.

xylphute

VINDICATORs le dénigrement c’était pour moi. Et oui je reconnais que denigre, comme malheureusement beaucoup de produit SUN qui ont été massacré par Oracle. Virtualbox souffre mais ce n’est pas le débat effectivement.

Sinon je suis curieux de savoir si @didierg a retenter de solutionner le bridge ou bien s’il peut nous en dire plus sur le probleme rencontré ça sera toujours bon pour les utilisateurs de qemu/kvm

didierg

xylphute Sinon je suis curieux de savoir si @didierg a retenter de solutionner le bridge

J’ai avancé. En spécifiant “Bridge device” et “vibr0” dans les paramètres de la carte réseau de la VM je peux communiquer entre host et guest.

Le problème qui subsiste est que mon host est sur le réseau de ma box 192.168.1.0/24 alors que ma VM est sur le réseau 192.168.122.0/24. De même les DNS ne sont pas ceux que j’ai définis au niveau du réseau de mon host.

De mémoire avec VirtualBox, mes VM étaient sur le réseau 192.168.1.0/24 et les DNS étaient ceux du host.

VINDICATORs

didierg

Un petit jeux pour ajouter les bonnes routes sur tes hôtes. C’est pas automatique, c’est pour cela que j’ai mis la partie de la doc qui en parle : https://doc.fedora-fr.org/wiki/Infrastructure_KVM/QEMU%2BKubernetes%2BCEPH#Configuration_R%C3%A9seaux_:

Mais bon créer un réseau Open permet plus de souplesse surtout si tu as plusieurs machines.
Mais il faut revoir les tables de routages sur chacune d’elle.

xylphute

J’ai remarqué aussi cette différence de sous réseau. Néanmoins, bien que la VM peut communiquer avec l’host elle peut communiquer également avec les autres périphériques en réseau.

Je n’ai pas cherché plus loin parce que ça fonctionne.

didierg

Ne serait-il pas simplement possible d’indiquer au guest qu’il doit utiliser le serveur DHCP du host ?

Sur le host:

$ sudo nmap --script broadcast-dhcp-discover
Starting Nmap 7.92 ( https://nmap.org ) at 2025-10-18 17:20 CEST
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     Interface: enp6s0
|     IP Offered: 192.168.1.18
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.1.1
|     IP Address Lease Time: 1d00h00m00s
|     Renewal Time Value: 12h00m00s
|     Rebinding Time Value: 21h00m00s
|     Subnet Mask: 255.255.255.0
|     Domain Name Server: 192.168.1.1
|     Domain Name: home
|     Broadcast Address: 192.168.1.255
|_    Router: 192.168.1.1
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.36 seconds

Sur le guest:

$ sudo nmap --script broadcast-dhcp-discover
Starting Nmap 7.92 ( https://nmap.org ) at 2025-10-18 17:23 CEST
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     Interface: enp8s0
|     IP Offered: 192.168.122.185
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.122.1
|     IP Address Lease Time: 1h00m00s
|     Renewal Time Value: 30m00s
|     Rebinding Time Value: 52m30s
|     Subnet Mask: 255.255.255.0
|     Broadcast Address: 192.168.122.255
|     Router: 192.168.122.1
|_    Domain Name Server: 192.168.122.1
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.32 seconds

VINDICATORs

didierg

Normalement c’est possible, faudra que je regarde car cela fait un moment que j’utilise que le mode Open (Ouvert).

Après tu peux avoir accès à partir des autres machines, mais pas de l’hôte si je ne me trompe pas.

didierg

VINDICATORs Après tu peux avoir accès à partir des autres machines, mais pas de l’hôte si je ne me trompe pas.

Je n’ai fait que tests basiques avec ssh, telnet, ping et traceroute mais pour l’instant ça fonctionne dans les deux sens: host vers guest et guest vers host.