par Dans cette troisième partie de la série sur KVM, nous allons parler réseau.
Notre première VM étant branchée directement sur le bridge br0 d’Openvswitch, elle est dans le même réseau que l’hyperviseur.
Admettons que nous voulions aussi avoir la possibilité d’avoir des VMs dans un réseau interne à l’hyperviseur, ne disposant donc pas directement d’une « sortie » via l’eth0/br0 de ce dernier.
C’est ce que nous allons voir dans cet article.
I – Nouveau bridge
Tout d’abord, nous allons créer un nouveau bridge au sein d’Openvswitch.
# ovs-vsctl add-br brint
Nouveau bridge sobrement appelé brint.
Dans KVM, on va le définir dans un fichier back.xml :
<network> <name>ovs-back</name> <forward mode='bridge'/> <bridge name='brint'/> <virtualport type='openvswitch'/> </network>
Puis :
# virsh net-define back.xml # virsh net-start ovs-back # virsh net-autostart ovs-back
Sur l’hyperviseur, on va lui offrir la possibilité de communiquer sur ce bridge en passant par l’interface interne créée automatiquement.
Pour se faire :
# ip addr add 10.99.1.250 dev brint # ip link set brint up # ip route add 10.99.1.0/24 dev brint
II – Ajout d’une interface à la VM
Pour tester, nous allons brancher à chaud une nouvelle interface réseau à notre première VM. L’avantage de la virtualisation, car aller brancher une carte réseau sur une vrai machine qui tourne, je ne m’y risquerais pas…
Pour voir déjà l’existant :
# virsh domiflist debianmano
On lui ajoute l’interface ainsi :
# virsh attach-interface debianmano network ovs-back --model virtio --target debianmano.1 --mac 52:54:00:11:11:12 --persistent
Au passage, pour détacher, c’est :
# virsh detach-interface debianmano bridge --mac 52:54:00:11:11:12 --config
Si on regarde le fichier de configuration :
# virsh edit debianmano
On peut voir la section pour cette interface qui a été ajoutée :
... <interface type='network'> <mac address='52:54:00:11:11:12'/> <source network='ovs-back'/> <target dev='debianmano.1'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </interface> ...
Puis dans la VM debianmano :
# virsh console debianmano
On va regarder la nouvelle interface ajoutée :
debianmano# ip a
Ici, c’est enp7s0 qui est ajoutée. Donc :
debianmano# ip addr add 10.99.1.1 dev enp7s0 debianmano# ip link set enp7s0 up debianmano# ip route add 10.99.1.0/24 dev enp7s0
On teste un ping vers l’hyperviseur :
debianmano# ping 10.99.1.250
Et dans l’hyperviseur :
# ping 10.99.1.1
Ceci doit fonctionner sans encombres.
III – Réflexions
On va faire une petite pause pour voir comment utiliser au mieux tout cela.
Très souvent, dans le cas ou l’on a besoin d’isoler un réseau de VMs sur un hyperviseur, le plus simple est d’effectuer l’interconnexion des réseaux (externe et interne) au niveau de l’hyperviseur. Typiquement ce qui est utilisé avec les hyperviseurs de type II si on ne cherche pas à complexifier.
Ici, on pourrait le faire en autorisant le forward IP sur l’hyperviseur, plus le lien sur le bridge interne crée auparavant, les régles de NAT…
Coté VM, on les connecterait au brint, en déclarant l’adresse IP de l’hyperviseur sur ce bridge en gateway.
Ok, cela fonctionne….
…mais je n’aime pas.
Quand je virtualise, je veux que l’hyperviseur ne fasse que cela.
Pour le routage vers le réseau interne des VMS, j’utilise une VM spécifique avec un lien sur le br0 (et donc une IP « externe ») et un lien sur le brint. C’est elle qui s’occupera du forward, du nat, etc…
L’hyperviseur garde son IP « principale » uniquement pour l’administration. Et il garde aussi le contact avec les VM mais uniquement pour de la gestion.
IV – Debianmano en Routeur
Ce qu’on va faire pour tester, c’est transformer notre première VM en routeur :
debianmano# echo 1 > /proc/sys/net/ipv4/ip_forward
Puis
debianmano# iptables -t nat -A POSTROUTING -s 10.99.1.0/24 -j SNAT --to 192.168.1.100
Son IP « externe » étant, vous l’aurez compris 192.168.1.100
V – Nouvelle VM
On va donc maintenant faire une machine uniquement branchée sur brint :
# virt-install --name newvm \ --vcpus 1 \ --cpu host \ --ram 1024 \ --location /img/debian-10.2.0-amd64-netinst.iso \ --disk pool=kvm-lvm,size=4,bus=virtio \ --network network:ovs-back,model=virtio,target=newvm.0 \ --graphics none \ --console pty,target_type=serial \ --extra-args='console=ttyS0' \ --os-variant debian10
On fait l’installation avec pour le réseau, une IP du genre 10.99.1.2, Gateway 10.99.1.1 (la première VM).
Une fois l’installation effectuée et la VM démarrée :
#virsh console newvm
On doit pouvoir pinguer debianmano :
newvm# ping 10.99.1.1
Également l’hyper (qui est encore présent sur le même réseau) :
newvm# ping 10.99.1.250
Par contre, la route passe bien par la premiere VM :
newvm# ip route
renvoie :
default via 10.99.1.1 dev enp1s0 onlink 10.99.1.0/24 dev enp1s0 proto kernel scope link src 10.99.1.2
Depuis debianmano et l’hyperviseur, on doit également pouvoir pinguer newvm sur son IP 10.99.1.2.
VI – Conclusion
Le réseau interne est fonctionnel, nous avons la seconde VM qui communique avec l’extérieur par le biais de la VM routeur. L’hyperviseur ne gère en rien le routage.
C’est bien, mais pas top, car j’aime utiliser les VLANs et nous allons voir justement comment les intégrer dans l’article suivant.
