KVM : partie réseau

I Présentation

Nous allons voir la partie réseau dans KVM. Il va être abordé les bridges qui sont également nommés « ponts » ou « réseaux virtuels » (virtual network) dans KVM.

Un bridge est un switch virtuel. Présent depuis longtemps dans le noyaux Linux, il a permis dans un premier temps de faire un switch à partir des cartes réseaux d’un PC. La où cela devient intéressant c’est la possibilité de brancher des cartes réseaux virtuelles (de vm 🙂 ) et de faire le pont (ou pas ) vers une ou plusieurs cartes physiques et accéder ainsi à d’autres réseaux extérieurs.

L’objectif est donc de montrer comment créer ces switchs et de les associer aux VM gérées par KVM.

Cette présentation a été réalisée sous ubuntu 20.04.

II Management des réseaux

II.1 Visualiser les réseaux KVM (et bridges)

Lister les réseaux virtuels vue par KVM via la comande « virsh » :

xavior@mon_pc:~$ virsh net-list --all
 Name              State    Autostart   Persistent
----------------------------------------------------
 default           active   yes         yes
 mon_reseau_nat    active   yes         yes
 mon_reseau_virt   active   yes         yes

Ainsi, nous voyons 3 switchs virtuels déjà existants. Le switch « default » est celui par défaut utilisable directement par KVM. Il propose un accès de type NAT avec le service DHCP. Les 2 autres ont été créés ensuite. Cette commande ne permet pas de lister les réseaux virtuels « externes » à KVM dans un premier.

En effet il est possible de créer des switchs virtuels sans passer par les commandes KVM, puis de les associer dans un deuxième temps. Ce cas sera vu un peu plus loin.

Il est également possible de lister les switchs via la commande « brctl » :

xavior@mon_pc:~$ brctl show
bridge name	bridge id		STP enabled	interfaces
virbr0		8000.5254008d5da7	yes		virbr0-nic
virbr1		8000.5254008d5da8	yes		virbr1-nic
							vnet1
virbr2		8000.5254003671f5	yes		virbr2-nic
							vnet0
							vnet2

En bleu les bridges présents sur la machine hôte. En violet les cartes réseau des VM qui sont actuellement en cours (si elles ne sont pas exécutées, alors les interfaces vnetX ne seront pas vus. Enfin en orange la carte du switch qui est branchée vers le monde extérieur. C’est par celle-ci que les données peuvent sortir ou pas en fonction de ce que l’on souhaite avoir.

La colonne STP indique que le protocole spanning tree est activé sur le bridge.

Autre manière de voir les bridges par le commande « ip » :

xavior@mon_pc:~$ ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether e4:b9:7a:6a:f2:52 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 5c:5f:67:ac:86:77 brd ff:ff:ff:ff:ff:ff
    inet 192.168.217.203/24 brd 192.168.217.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 3360sec preferred_lft 3360sec
    inet6 fe80::5b11:33ca:5d35:63c3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:8d:5d:a8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.254/24 brd 192.168.150.255 scope global virbr1
       valid_lft forever preferred_lft forever
5: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr1 state DOWN group default qlen 1000
    link/ether 52:54:00:8d:5d:a8 brd ff:ff:ff:ff:ff:ff
6: virbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:36:71:f5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr2
       valid_lft forever preferred_lft forever
7: virbr2-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr2 state DOWN group default qlen 1000
    link/ether 52:54:00:36:71:f5 brd ff:ff:ff:ff:ff:ff
8: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:8d:5d:a7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
9: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:8d:5d:a7 brd ff:ff:ff:ff:ff:ff
17: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr2 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:1e:bd:e2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe1e:bde2/64 scope link 
       valid_lft forever preferred_lft forever
18: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:aa:59:56 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:feaa:5956/64 scope link 
       valid_lft forever preferred_lft forever
19: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr2 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:41:24:45 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe41:2445/64 scope link 
       valid_lft forever preferred_lft forever

Par couleur :

• carte de bouclage (blanc) ;
• cartes physiques filaire et wifi de l’hôte,(rose) ;
• les bridges ou switch virtuels (bleu) ;
• les interfaces du bridge (en orange) ;
• les cartes réseaux des VM allumées (violet).

Voir les propriétés d’un réseau :

xavior@mon_pc:~$ virsh net-info --network mon_reseau_virt 
Name:           mon_reseau_virt
UUID:           3cb297d0-9a6d-4890-8fea-848e33c6ec88
Active:         yes
Persistent:     yes
Autostart:      yes
Bridge:         virbr2

Ces informations permettent de savoir :

• si le switch est actif ou non ;
• si il sera chargé à chaque redémmarage de l’hôte ;
• le nom vu sous Linux (ici virbr2).

Pour connaitre le détail d’un réseau et des fonctionnalités mises en oeuvre :

xavior@mon_pc:~$ virsh net-dumpxml mon_reseau_nat 
<network connections='1'>
  <name>mon_reseau_nat</name>
  <uuid>603a985c-7549-4e8e-ae56-e3c3b4f8c987</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='52:54:00:8d:5d:a8'/>
  <ip address='192.168.150.254' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.150.50' end='192.168.150.220'/>
    </dhcp>
  </ip>
</network>

Ainsi ce switch :

• utilise le principe de NAT ;
• la pate WAN possède une mac adresse propre ;
• porte le nom de « virbr1 » ;
• a une plage d’adresse LAN 192.168.150.0/24 et que l’adresse IP de son interface est 192.168.150.254 ;
• délivre un service DHCP pour une plage IP allant de 192.168.150.50 à 220.

Il est aussi possible de visualiser les connexions réseaux par un outil graphique via « virt-manager » :

Après le lancement, cliquer sur « Détails de la connexion » dans le menu de l’application :

Cliquer sur l’onglet « Réseaux virtuels » :

Possibilité de voir l’équivalent de la configuration en XML associée :

Enfin, mais pas la dernière méthode, il est possible de visualiser les bridges via l’interface graphique « nm-connection-editor » :

Avec le détail comme suivant :

II.2 Gestion réseau (switch virtuel)

Sous KVM les swicths sont appelés « réseau » ou « network ». C’est une couche supplémentaire au dessus des bridges et qui permet d’ajouter des services supplémetaires à de simple « bridges ».

Nous allons voir la mise en oeuvre générale de déclaration d’un réseau KVM puis la création :

• d’un réseau supportant le NAT avec le service DHCP ;
• d’un réseau isolé de tout autre réseau ;
• d’un réseau dit « routé » ;
• d’un réseau utilisant un bridge extérieur (avec la création de ce dernier) ;

Enfin nous terminerons par la suppression de ces réseaux ».

II.2.1 Création d’un réseau avec virsh

La création d’un réseau se fait en plusieurs étapes en ligne de commande :

• création à partir d’un fichier xml ;
• activation du réseau ;
• montage automatique (ou pas) du réseau au démarrage de l’hôte.

Le réseau est associé à un bridge. Si ce dernier n’existe pas alors il sera créé automatiquement.

II.2.1.1 Création d’un réseau de type NAT

Donc dans un premier temps nous allons définir le fichier xml que l’on nommera « mon_reseau_nat1 ».

<network>
  <name>reseau_NAT1</name>
  <forward mode="nat"/>
  <domain name="mon_reseau_NAT1"/>
  <ip address="192.168.199.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.199.128" end="192.168.199.254"/>
    </dhcp>
  </ip>
</network>

Dans le fichier xml il est demandé :

• un réseau NATé avec l’Hôte (pas de carte réseau définie, elle sera automatiquement selectionnée) ;
• un réseau local dans la plage d’adresse 192.168.199.0 avec comme passerelle 192.168.199.1 ;
• un service DHCP délivrant des adresses IP de 192.168.199.128 à .254.

Nous allons créer ce réseau avec « virsh net-define » :

xavior@mon_pc:~$ virsh net-define --file mon_reseau_nat1 
Network reseau_NAT1 defined from mon_reseau_nat1

Puis nous allons l’activer et faire en sorte qu’il soit démarré à chaque démarrage de l’hôte :

xavior@mon_pc:~$ virsh net-start --network reseau_NAT1 
Network reseau_NAT1 started
xavior@mon_pc:~$ virsh net-autostart --network reseau_NAT1 
Network reseau_NAT1 marked as autostarted

On vérifie si tout s’est bien passé :

xavior@mon_pc:~$ virsh net-list --all
 Name              State    Autostart   Persistent
----------------------------------------------------
 default           active   yes         yes
 mon_reseau_nat    active   yes         yes
 mon_reseau_virt   active   yes         yes
 reseau_NAT1       active   yes         yes

A ce stade le réseau est opérationnel.

Si on regarde maintenant la configuration du réseau « reseau_NAT1 », on s’aperçoit qu’un certain nombre de lignes ont été ajoutées (en vert) :

<network>
  <name>reseau_NAT1</name>
  <uuid>d701d126-8283-4526-a409-5d9092152925</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr3' stp='on' delay='0'/>
  <mac address='52:54:00:16:c7:71'/>
  <domain name='mon_reseau_NAT1'/>
  <ip address='192.168.199.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.199.128' end='192.168.199.254'/>
    </dhcp>
  </ip>
</network>

Ainsi automatiquement :

• un « uuid » a été défini ;
• dans le cadre du NAT, les ports de réponse ont été précisés ;
• un bridge nommé « virbr3 » a été défini et créé ;
• une adresse MAC du bridge a été définie.

A savoir qu’il est possible de définir soi-même ces valeurs.

Maintenant nous allons associer ce réseau à la carte réseau de la VM. Pour cela nous allons utiliser « virt-manager« , sélectionner les propriétés de la VM, et se positioner sur la carte réseau. Puis dans « source du réseau » sélectionner le réseau « reseau_NAT1 » :

Enfin lancer la VM et vérifier :

On s’aperçoit ainsi que la carte réseau a bien reçu une adresse IP dans la tranche IP définie, ainsi qu’une passerelle et l’@IP de résolution DNS.

II.2.1.2 Création d’un réseau isolé

Le fichier XML ressemble à celui d’un NAT mais sans les balises « <forward> ». Dans le cas ci-dessous on demande également le service DHCP. Le fichier associé sera « mon_reseau_isole ».

<network>
  <name>reseau_isole</name>
  <domain name="reseau_isole"/>
  <ip address="192.168.102.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.102.128" end="192.168.102.254"/>
    </dhcp>
  </ip>
</network>

et les commandes pour activer ce réseau :

xavior@mon_pc:~$ virsh net-define mon_reseau_isole 
Network reseau_isole defined from mon_reseau_isole

xavior@mon_pc:~$ virsh net-start reseau_isole 
Network reseau_isole started

xavior@mon_pc:~$ virsh net-autostart reseau_isole 
Network reseau_isole marked as autostarted

Ce qui donne la définition finale suivante :

xavior@xavior-Latitude-7490:~$ virsh net-dumpxml reseau_isole 
<network>
  <name>reseau_isole</name>
  <uuid>1ae3c735-286f-4411-8a7a-b974a36c990f</uuid>
  <bridge name='virbr5' stp='on' delay='0'/>
  <mac address='52:54:00:93:b1:5d'/>
  <domain name='reseau_isole'/>
  <ip address='192.168.102.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.102.128' end='192.168.102.254'/>
    </dhcp>
  </ip>
</network>

L’adresse IP 192.168.102.1 n’est pas une passerelle mais l’adresse IP du service DHCP.

Ainsi toutes les VM qui ont leurs cartes virtuelles associées à ce réseau virtuel ne pourront pas discuter vers l’extérieur mais seulement entre elles (sauf pour la résolution DNS).

II.2.1.3 Création d’un réseau routé

Ce mode permet de relier une plage d’adresses IP directement vers la ou les VM. Il n’y a donc pas de mécanisme de type « NAT  » d’implémenté. C’est principalement utilisé dans le cadre de DMZ ou d’hébergment de serveurs virtuels (VM qui possède sa propre ip publique, CQFD)

Dans ce post il ne sera pas montré en détail ce mode.

II.2.1.4 Création d’un réseau à partir d’un bridge déjà existant

Nous allons créer un réseau virtuel (bridge) de type NAT avec DHCP interne sans passer par les outils virsh. Ensuite nous indiquerons à KVM d’utiliser ce bridge externe.

II.2.1.4.1 Création manuelle via la commande « nmcli »

Création d’un bridge :

La création du pont portera le nom de « br0 ». Ceci pour le distinguer des ponts virtuels créés par « virsh » dont les noms commencent par « virbrX ».

Pour cela nous allons utiliser la commande « nmcli » et commencer par créer le bridge comme suivant :

xavior@mon_pc:~$ nmcli connection add ifname br0 type bridge con-name br0
Connexion « br0 » (c8000ccb-403a-4fda-a7ac-55426f673a6a) ajoutée avec succès.

Ajout d’une interface au réseau. Ce sera une interface physique du PC Hôte :

Toujours avec la commande « nmcli » nous créons une interface réseau associée au bridge qui nous permettra d’accéder au réseau extérieur.

xavior@mon_pc:~$ nmcli connection add type bridge-slave ifname enp0s31f6 master br0
Connexion « bridge-slave-enp0s31f6 » (0962144e-5828-4e0f-ae9b-311a086528e5) ajoutée avec succès.

Un nom arbritraire a été donné à la connexion vers l’interface physique (bridge-slave-enp0s31f6). Il est possible d’en spécifier un manuellement comme « bridge-br0 » qui est souvent utilisé sur d’autres documentation internet. Nous concernant nous allons garder cette appellation.

Activation du pont « br0 » :

Pour activer le switch avec la commande « nmcli » :

xavior@mon_pc:~$ nmcli con up br0
Connexion activée (master waiting for slaves) (Chemin D-Bus actif : /org/freedesktop/NetworkManager/ActiveConnection/68)

Indiquer au pont que la communication est partagée vers l’extérieur (fonction NAT):

xavior@mon_pc:~$ nmcli connection modify br0 ipv4.method shared

A ce stade, le mode DHCP est activé automatiquement. Mais nous n’avons pas défini la plage d’adresses IP. Si on continue sans rien changer, la plage utilisable sera en 10.42.0.1/24.

Indiquer la plage d’adresses IP que l’on souhaite :

xavior@mon_pc:~$ nmcli connection modify br0 ipv4.addresses "192.168.204.1/24"

Pour faire prendre en compte les dernières valeurs, il faut relancer le bridge :

xavior@mon_pc:~$ nmcli connection down br0 
Connexion « br0 » désactivée (chemin D-Bus actif : /org/freedesktop/NetworkManager/ActiveConnection/88)
xavior@mon_pc:~$ nmcli connection up br0 
Connexion activée (master waiting for slaves) (Chemin D-Bus actif : /org/freedesktop/NetworkManager/ActiveConnection/90)

Vérification :

• via la commande « ip« 

xavior@mon_pc:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether e4:b9:7a:6a:f2:52 brd ff:ff:ff:ff:ff:ff
...
62: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 22:f6:a6:33:44:48 brd ff:ff:ff:ff:ff:ff
    inet 192.168.204.1/24 brd 192.168.204.255 scope global noprefixroute br0
       valid_lft forever preferred_lft forever

• ou via la commande « nmcli » qui va donner toutes les propriétés du bridge :

xavior@mon_pc:~$ nmcli connection show br0 
connection.id:                          br0
connection.uuid:                        c8000ccb-403a-4fda-a7ac-55426f673a6a
connection.stable-id:                   --
connection.type:                        bridge
connection.interface-name:              br0
connection.autoconnect:                 oui
...
connection.wait-device-timeout:         -1
ipv4.method:                            shared
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         192.168.204.1/24
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                non
ipv4.ignore-auto-dns:                   non
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                oui
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     non
ipv4.may-fail:                          oui
ipv4.dad-timeout:                       -1 (default)
ipv6.method:                            auto
ipv6.dns:                               --
...
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/Settings/49
GENERAL.ZONE:                           --
GENERAL.MASTER-PATH:                    --
IP4.ADDRESS[1]:                         192.168.204.1/24
IP4.GATEWAY:                            --
IP4.ROUTE[1]:                           dst = 192.168.204.0/24, nh = 0.0.0.0, mt = 425

Les valeurs en majuscules (IP4.XXX) indiquent celles qui sont actuellement prise en compte. Elles changent après l’activation du bridge en fonction des valeurs en minuscule.

II.2.1.4.2 Suppression manuelle via la commande « nmcli »

Il faut supprimer l’interface associé au bridge puis le bridge lui-même.

Ainsi avec « nmcli » :

xavior@mon_pc:~$ nmcli connection delete bridge-slave-enp0s31f6 
Connexion « bridge-slave-enp0s31f6 » (0962144e-5828-4e0f-ae9b-311a086528e5) supprimée.
xavior@mon_pc:~$ nmcli connection delete br0 
Connexion « br0 » (c8000ccb-403a-4fda-a7ac-55426f673a6a) supprimée.

Vérification :

xavior@mon_pc:~$ nmcli connection show 
NAME                 UUID                                  TYPE      DEVICE 
xavior               6652228b-eb27-4dc4-8ac2-47ae71436486  wifi      wlp2s0 
virbr0               3e8e35b6-6a63-494a-863f-25e9737a62f5  bridge    virbr0 
virbr1               39874e38-0033-49da-9032-a637055e8142  bridge    virbr1 
virbr2               e46b7321-eb5d-40f8-9338-a2c9c87ec639  bridge    virbr2 
virbr3               ec16a556-92bb-4c37-9cb6-ada06a254bb3  bridge    virbr3 
virbr4               c28f2679-0cd3-4241-bcfe-eb7fdb8b882c  bridge    virbr4 
virbr5               8eeeb4d8-9075-47f3-bc10-9ac8a97d91d9  bridge    virbr5 
Connexion filaire 1  57aebe66-000e-3a04-a5cd-d90f02846365  ethernet  --     
Pif_Paf_Pouf_5G      f6293849-a986-46d6-b051-c262b755ad9a  wifi      --     
xavchrys2            acf9fb68-84e6-442e-9aca-5831ff0a268b  wifi      --  

A ce stade il n’y a plus de bridge.

II.2.1.4.3 Création via une interface graphique

Il est possible de créer un bridge via une interface graphique. Nous allons utiliser la commande « nm-connection-editor ».

xavior@mon_pc:~$ nm-connection-editor &
[7] 351950
[6]   Fini                    nm-connection-editor

Ainsi la fenêtre suivante apparaît :

Nous pouvons voir l’existence de bridge (pont) déjà présents (qui ont été créés avec virsh ici). Nous allons maintenant créer notre propre pont externe à KVM.

Pour cela cliquer sur le bouton « + » en bas à gauche :

Dans la boite déroulante, choisir « Pont » puis cliquer sur le bouton « Créer » :

A ce stade, le pont est créé. Nous allons maintenant ajouter une interface physique qui permettra de faire le lien vers l’extérieur.

Sous « Pont entre connexions », cliquer sur le bouton « Ajouter » :

Selectionner « Ethernet » puis cliquer sur le bouton « Créer » :

On va laisser le nom donné par l’outil graphique. Pour rappel en ligne de commande le nom était « bridge-slave-enp0s31f6« .

A ce stade il n’est pas neccessaire de définir manuellement une interface physique dans la liste ‘Périphérique ». Ce sera fait automatiquement.

Cliquer sur le bouton « Enregistrer » pour retrouver la fenêtre suivante :

On remarque que l’interface physique « Esclave bridge0 1 » est présente dans la liste « Pont entre connexions ».

Nous allons maintenant faire en sorte que le bridge communique vers l’extérieur. Pour cela cliquer sur l’onglet « Paramètres IPv4 » :

Dans la liste « Méthode », sélectionner le mode « Partagé avec d’autres ordinateurs« . A ce stade le bridge communiquera vers l’extérieur et un réseau DHCP est activé.

Pour spécifier la plage IP du DHCP il faut l’indiquer dans « Adresse (optionnel) ». Pour cela cliquer sur le bouton « Ajouter » et renseigner comme suivant :

Une fois fait cliquer sur le bouton « Enregistrer ». L’écran suivant fait apparaître le nom bridge :

Ainsi nous avons notre bridge « Connexion pont 1 » (« br0″ quand il a été créé manuellement) et l’association à la carte physique ‘Esclave bridge0 1 ».

A ce stade la configuration est terminée.

Mais il va falloir activer manuellement ce pont :

xavior@mon_pc:~$ nmcli connection up "Connexion pont 1"
Connexion activée (master waiting for slaves) (Chemin D-Bus actif : /org/freedesktop/NetworkManager/ActiveConnection/93)
xavior@mon_pc:~$ nmcli connection up "Esclave bridge0 1"
Connexion activée (chemin D-Bus actif : /org/freedesktop/NetworkManager/ActiveConnection/95)

Vérification :

xavior@mon_PC:~$ nmcli connection show
NAME                 UUID                                  TYPE      DEVICE    
Connexion pont 1     74e84b60-8e9b-4499-a04b-ede32c150ad3  bridge    bridge0   
xavior               6652228b-eb27-4dc4-8ac2-47ae71436486  wifi      wlp2s0    
virbr0               3e8e35b6-6a63-494a-863f-25e9737a62f5  bridge    virbr0    
virbr1               39874e38-0033-49da-9032-a637055e8142  bridge    virbr1    
virbr2               e46b7321-eb5d-40f8-9338-a2c9c87ec639  bridge    virbr2    
virbr3               ec16a556-92bb-4c37-9cb6-ada06a254bb3  bridge    virbr3    
virbr4               c28f2679-0cd3-4241-bcfe-eb7fdb8b882c  bridge    virbr4    
virbr5               8eeeb4d8-9075-47f3-bc10-9ac8a97d91d9  bridge    virbr5    
Esclave bridge0 1    3c356e22-93b2-445b-95e8-ac0f5eaf6b58  ethernet  enp0s31f6 
Connexion filaire 1  57aebe66-000e-3a04-a5cd-d90f02846365  ethernet  --        
Pif_Paf_Pouf_5G      f6293849-a986-46d6-b051-c262b755ad9a  wifi      --        
xavchrys2            acf9fb68-84e6-442e-9aca-5831ff0a268b  wifi      --        

A ce stade le pont est créé et utilisable.

II.2.1.4.4 Association du bridge au réseau KVM :

Nous allons maintenant indiquer à KVM d’utiliser le bridge (et ainsi de ne pas le faire créér).

Ainsi on crée un fichier XML nommé « mon_reseau_pont1 » qui contiendra les données suivantes :

<network >
  <name>Connexion_pont_1</name>
  <forward mode="bridge"/>
  <bridge name="Connexion pont 1"/>
</network>

Ainsi on spécifie le mode « bridge » pour indiquer qu’il faut utiliser un bridge déjà existant ainsi que le nom du bridge à utiliser (« connexion pont 1 »)

Maintenant on l’enregistre dans KVM :

xavior@mon_pc:~$ virsh net-define --file mon_reseau_pont1 
Network Connexion_pont_1 defined from mon_reseau_pont1

xavior@mon_pc:~$ virsh net-start --network Connexion_pont_1 
Network Connexion_pont_1 started

xavior@mon_pc:~$ virsh net-autostart --network Connexion_pont_1 
Network Connexion_pont_1 marked as autostarted

Et pour bien s’assurer que ce pont est pris en compte avec KVM :

xavior@mon_pc:~$ virsh net-list 
 Name                State    Autostart   Persistent
------------------------------------------------------
 Connexion_pont_1    active   yes         yes
 default             active   yes         yes
 mon_reseau_br0      active   yes         yes
 mon_reseau_nat      active   yes         yes
 mon_reseau_NAT2     active   yes         yes
 mon_reseau_route1   active   yes         yes
 mon_reseau_virt     active   yes         yes
 reseau_isole        active   yes         yes

A ce stade c’est terminé.

II.2.1.4.5 Tests

Nous allons voir au sein d’un VM si cela fonctionne. Pour cela on choisit une VM déjà installée et on définit le réseau virtuel avec ce pont :

III Aller plus loin et ressources

Nous avons vu une introduction globale au réseaux virtuels sous KVM et Linux.

Pour aller plus loin :

• créer une VM avec plusieurs cartes réseaux virtuelles associées à des switchs virtuels différents ;
• mettre en oeuvre le mode « routed » ;
• utiliser un switch virtuel de type OpenVSwitch ;
• réseau commun antre 2 hyperviseurs KVM ;
• vision des réseaux côté « IPATBLES » et voir différence quand managé par KVM(libvirt) ou par linux(nmcli) ;
• etc.

Ressources internet :

• vmnet –> cartes virtuelles (nommée également TAP) des VM branchées sur un bridge
  • https://unix.stackexchange.com/questions/52855/what-is-the-difference-between-virbr-and-vnet
• Ressources KVM (libvirt) :
  • https://libvirt.org/formatnetwork.html
    https://wiki.libvirt.org/page/Networking
    
• Gestion bridge (Linux)
  • nmcli : https://developer-old.gnome.org/NetworkManager/stable/nmcli-examples.html
  • ip link et autres : https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking#bridge