{{tag>application software sysadmin kvm vm virsh réseau network}}
====== KVM : Gestion des réseaux via virsh ======
===== Prérequis =====
- L'utilisateur doit faire parti du groupe ''libvirt'' pour pouvoir interagir avec la CLI ''virsh'' ;
- ''virsh'' doit être lancé en **mode système** via l'option ''%%--connect qemu:///system%%'' (comportement par défaut).
Lorsque virsh est exécuté en mode session, les réseaux ne sont pas disponibles/visibles mais les VMs peuvent être connectées aux ponts existants (actifs sur l’hôte).
Lister les réseaux disponibles :
virsh net-list --all
Afficher les détails du réseau "default" :
virsh net-info default
===== A propos des types de réseaux =====
:TODO_DOCUPDATE:
Lors de la création d'un réseau virtuel avec **virt-manager**, on a le choix entre plusieurs modes de connexion :
* Le mode **NAT**((**N**etwork **A**ddress **T**ranslation)) permet aux VMs de se connecter à Internet au travers de l’hôte tout en maintenant une isolation vis-à-vis des réseaux locaux et des autre VMs (mode masquarade)
* Le mode **routé**
* Le mode **ouvert**
* Le mode **isolé**(isolated) : les VMs peuvent communiquer entre-elles mais n'accèdent pas à Internet au travers de l'hote hyperviseur.
* Le mode pool SR-IOV
===== Créer un réseau isolé avec virsh =====
Comme pour les domaines (définitions de VMs) on peut exporter une configuration existante en XML et y apporter les modifications nécessaires à notre nouvelle connexion via la commande ''**virsh net-dumpxml**'').
virsh net-dumpxml default > my-network.xml
Pour créer une réseau en mode isolé, il suffit de créer un périphérique de type pont (bridge) sans option de nattage (''%%%%'') ou de routage (''%%%%''). Les VMs connectées à ce pont (vswitch) pourront communiquer entre-elles sans communiquer vers l'extérieur.
Ici on souhaite définir un réseau interne isolé pour interconnecter plusieurs VMs sans connexion Internet.
vm-internal
internal network
vswich without Internet connection, no DHCP.
Ce premier exemple de configuration est minimaliste. L'hyperviseur ne fournira aucun service d’auto configuration réseau (DHCP ou résolution DNS). Il définit une interface ''virbr1'' (vswitch) sur l'hyperviseur qu'il faudra communiquer aux VMs que l'on souhaite relier.
Une fois le fichier enregistré et modifié, pour définir le nouveau réseau. On peut utiliser les commandes :
* **virsh net-define** (pour créer un réseau permanent) ;
* **virsh net-create** (pour un définition transitoire/temporaire).
# Création du réseau permanent à partir du fichier XML
virsh net-define --validate --file vm-internal.xml
# Lister les réseaux
virsh net-list --all
Name State Autostart Persistent
--------------------------------------------------
default active yes yes
vm-internal inactive no yes
# Activer le réseau
virsh net-start vm-internal
# Démarrer automatiquement le réseau
virsh net-autostart vm-internal
# Détails du nouveau réseau
virsh net-info vm-internal
Name: vm-internal
UUID: 3f66061e-4dd0-449f-8917-d73cd3f1222b
Active: yes
Persistent: yes
Autostart: yes
Bridge: virbr1
On note que le pont d'accès au réseau est **virbr1** : il faudra fournir ce pont aux VMs que l'on souhaite interconnecter.
Les fichiers de configuration des réseaux persistants sont stockés dans le répertoire ''/etc/libvirt/qemu/networks/''
===== Joindre un réseau =====
Pour qu'une VM puisse joindre le réseau, on définit une nouvelle interface utilisant le pont dédié au réseau :
Si l'on souhaite conserver l'interface et la connexion au réseau après redémarrage, ajouter l'argument **%%--persistent%%**
# Connexion permanente de la VM ftp-server au réseau vm-internal
virsh attach-interface --persistent --type bridge --source virbr1 --model virtio ftp-server
# Connecte ponctuellement la VM file-server déjà démarrée au réseau vm-internal
virsh attach-interface --live --type bridge --source virbr1 --model virtio file-server
# Connecte ponctuellement la VM debian12-amd64-novideo déjà démarée au réseau vm-internal
virsh attach-interface --live --type bridge --source virbr1 --model virtio debian12-amd64-novideo
Dans notre cas le réseau ne comporte pas de DHCP : il faudra configurer manuellement et démarrer les interfaces sur chaque VMs pour qu'elles puissent communiquer sur le réseau vm-internal.
On peut rencontrer quelques difficultés à joindre un réseau de type pont lorsque virsh s'exécute en **mode session**. Confère note [[software/applications/qemu/depannage/failed-to-parse-default-acl-file|Echec de connexion en mode session]].
===== Déconnecter une VM d'un réseau =====
Pour déconnecter une VM d'un réseau, on retire l'interface vers celui-ci :
# Lister toutes les interfaces du domaine et relever la MAC
virsh domiflist tethys
# Supprimer l'interface en la désignant par sa MAC
virsh detach-interface tethys --type bridge --mac "52:54:00:12:2f:ae" --config
===== Pare-feu =====
Selon la politique de filtrage appliquée sur l'hôte exécutant le service de virtualisation KVM, des règles supplémentaires peuvent être nécessaires.
Lorsqu'une VM démarre, elle rejoint le réseau virtuel de type pont "virbr0" c'est via ce réseau qu'elle accède à Internet au travers de la connexion de l’hôte.
Dans l'exemple ci dessous le filtrage préexistant refuse le trafic entrant permettant l'auto-configuration de l'interface de la VM :
juil. 05 09:28:02 node-7c87 kernel: [FW] [REJECT] [RID=666] IN=virbr0 OUT= MAC=ff:ff:ff:ff:ff:ff:52:54:00:1d:20:08:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
On introduit une règle de filtrage supplémentaire autorisant les requêtes DHCPDISCOVER entrant par l'interface "virbr0" :
Depuis **nft** en mode interactif :
insert rule ipfilter inbound position 17 iif "virbr0" ip daddr 255.255.255.255 udp sport 68 udp dport 67 log prefix "[FW] [ACCEPT] [RID=18] " level notice counter accept comment "Autorise autoconfiguration VMs KVM"
KVM utilise dnsmasq pour fournir la configuration aux VMs, selon la politique de filtrage en place il faudra également autorisé le trafic sortant :
juil. 05 10:00:32 node-7c87 dnsmasq-dhcp[1698]: DHCPDISCOVER(virbr0) 192.168.122.43 52:54:00:1d:20:08
juil. 05 10:00:32 node-7c87 dnsmasq-dhcp[1698]: DHCPOFFER(virbr0) 192.168.122.43 52:54:00:1d:20:08
juil. 05 10:00:32 node-7c87 dnsmasq-dhcp[1698]: Error sending DHCP packet to 192.168.122.43: Operation not permitted
juil. 05 10:00:32 node-7c87 kernel: [FW] [REJECT] [RID=667] IN= OUT=virbr0 SRC=192.168.122.1 DST=192.168.122.43 LEN=328 TOS=0x00 PREC=0xC0 TTL=64 ID=13364 PROTO=UDP SPT=67 DPT=68 LEN=308
Ici on insère une règle de filtrage (depuis nft en mode interactif) :
insert rule ipfilter outbound position 39 oif "virbr0" udp sport 67 udp dport 68 log prefix "[FW] [ACCCEPT] [RID=61] " level notice counter accept comment "Autorise autoconfiguration VMs KVM (DHCPOFFER)"
Pour autoriser les connexions SSH :
insert rule ipfilter outbound position 34 oif "virbr0" tcp dport 22 log prefix "[FW] [ACCCEPT] [RID=62] " level notice counter accept comment "Autorise connexion SSH aux VMs KVM"
Pour que les VMs puissent avoir accès à Internet l’hôte doit également autoriser la transmission des paquets ([[netadmin:linux:ip-forwarding|forwarding]]) :
Dans cet exemple la configuration préexistante trace et mais rejette les transmissions de trafic :
list chain ipfilter forward
table ip ipfilter {
chain forward { # handle 3
type filter hook forward priority filter; policy drop;
log prefix "[FW] [REJECT] [RID=668] " counter packets 0 bytes 0 reject comment "Refuse toute transmission non explicitement autorisee" # handle 41
}
}
On peut autoriser les transmissions HTTP et HTTPS en provenance du
insert rule ipfilter forward iif "virbr0" oif "lan0" ct state new tcp dport { 80, 443 } log prefix "[FW] [REJECT] [RID=81] " level notice counter accept comment "Transfert le trafic web pour les VMs KVM"
insert rule ipfilter forward ct state established,related counter accept comment "Transfert les trafics des connexions explicitement autorisees"
===== Références =====
* https://fr.linux-console.net/?p=22230
* https://www.techtarget.com/searchitoperations/tip/Use-virsh-commands-to-manage-KVM-networking
* [[https://wiki.libvirt.org/VirtualNetworking.html|Les types de réseaux de libvirt (libvirt.org) (en)]]