Bonsoir,
J'ai un hyperviseur KVM sous CentOS 6.2. Cette machine possède une interface réseau physique (eth0) qui la relie à mon réseau local (192.168.1.0/24—chatillon.mydomain.com).
Sur mon LAN se trouve un serveur dnsmasq qui gère le DHCP et le DNS interne (pour le domaine chatillon.mydomain.com donc).
L'hyperviseur possède un bridge réseau (virt0) destiné à gérer le réseau interne pour les machines virtuelles. J'ai choisi de configurer le tout en NAT (mais à la main, je vais m'expliquer).
J'ai donc configuré un serveur dnsmasq également sur mon hyperviseur afin de fournir les services suivants :
- DHCP sur la plage 192.168.4.0/24 (l'hyperviseur possède l'adresse 192.168.4.1)
- DNS pour le domaine virt.mydomain.com et relai DNS pour les machines virtuelles
Des règles iptables permettent aux machines virtuelles de se connecter au reste du réseau, et également d'être contactées par le réseau.
Je possède pour les tests deux machines virtuelles : test01.virt.mydomain.com et test02.virt.mydomain.com, toutes les deux sous CentOS 6.2, avec le driver virtio.
Lorsque je tente une connexion depuis test01 vers test02, le prompt 'password' arrive instantanément, mais lorsque le mot de passe est saisi, la connexion prend presque une minute à s'établir.
J'ai alors désactivé le paramètre UseDNS du serveur SSH, qui résous le problème. Je l'ai ensuite activé à nouveau, puis ajouté l'hôte test02 dans le /etc/hosts de test01, ce qui avait également pour effet de résoudre mon problème.
J'ai alors incriminé le serveur dnsmasq. Il se trouve que lorsque je fais (le tout depuis test01) des nslookup test02 ou nslookup 192.168.4.11 (ip de test02), les résolutions fonctionnent, mais prennent un peu de temps, et ce de façon aléatoire… Les temps observés oscillent entre 0.5s et 1.5s. Je trouve que ces chiffres sont un peu excessifs, d'autant plus que tout est interne à une seule machine, puisque le serveur DNS est hébergé sur l'hyperviseur…
De ce fait, d'autres problèmes interviennent, notamment au niveau de l'authentification LDAP.
Pour information, un simple ldapsearch prend 15 secondes pour retourner 7 résultats… Lorsque je l'exécute depuis test02 (c'est lui qui héberge le serveur LDAP), alors le résultat est instantané…
J'ai alors effectué le même travail que pour SSH, à savoir ajouter l'hôte de test02 dans le fichier /etc/hosts, et là, le résultat est immédiat…
J'ai donc, je pense, confirmé avec deux services, que le serveur dnsmasq pose quelques soucis.
Je me permet donc de vous poser la configuration, afin d'essayer de trouver une solution à ce problème !
Le fichier /etc/hosts de l'hyperviseur se trouve ici : http://pastebin.com/TuXSgsPu
La configuration dnsmasq de l'hyperviseur se trouve ici : http://pastebin.com/yQxvtCxb
Un exemple de fichier /etc/resolv.conf d'une machine virtuelle : http://pastebin.com/K032ZBBz
PS : je rencontrais des problèmes avec virtio (les connexions ssh n'étaient pas possibles depuis l'exterrieur…). Ce problème a été résolu avec l'ajout de la ligne suivante dans le rc.local :
ethtool -K eth0 tx off sg off tso off gso off
# En fait, c'est dnsmasq le coupable, KVM est jusqu'à preuve du contraire innocent... !
Posté par Thomas Bétrancourt (site web personnel) . Évalué à 1.
Après avoir consulté dans le détail les logs de mes différents dnsmasq, je me suis aperçu qu'un phénomène bizarre se produisait…
Il se trouve qu'en fait, mes deux dnsmasq se floodent entre eux…
dnsmasq sur mon hyperviseur est sensé résoudre les noms .virt.mydomain.net et donner le reste à mon routeur. Mon routeur est configuré pour interroger mon hyperviseur pour les noms en .virt.mydomain.net et résoudre le reste via 8.8.8.8.
Il se trouve que le dnsmasq de mon hyperviseur envoi tout de même des requêtes en .virt.mydomain.net à mon routeur, qui a pour effet de boucle infinie (le routeur refile à l'hyperviseur, etc etc…).
Ce que je ne comprends pas, c'est que depuis mon hyperviseur j'ai ça :
[root@proliant dnsmasq.d]# nslookup test01 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
C'est qu'il arrive donc à les résoudre =S
Donc en gros, je suis complètement perdu, pourquoi ces DNS se jettent la balle comme ça…
Je ne sais pas si on peut configurer dnsmasq pour lui dire de ne pas faire suivre des requêtes sur un certain DNS. En gros lui dire "si tu ne sais pas résoudre toto.virt.mydomain.net, et bah, tu donnes une réponses négatives, tu demandes pas à tes copains". Car ce que je me rend compte, c'est que mon routeur transmet parfois aux DNS google des requêtes du type www.un-domaine-qui-n-existe-pas.fr.chatillon.mydomain.net.
Si on ne peut pas faire ce genre de choses, je crois que je reviendrais aux bonnes anciennes méthodes : bind9 + dhcpd…
Pas de problème pour mon proliant, mais pour mon routeur sous openwrt, je crois que ça sera pas une mince affaire…
Au secours !
PS : la bonne nouvelle, c'est que ma virtualisation semble fonctionner U_U
[^] # Re: En fait, c'est dnsmasq le coupable, KVM est jusqu'à preuve du contraire innocent... !
Posté par Thomas Bétrancourt (site web personnel) . Évalué à 1.
Finalement, j'ai fait comme ceci :
J'ai admis que le réseau virtuel sur l'hyperviseur était un réseau indépendant, et c'est pourquoi le dnsmasq correspondant interroge les DNS public dans le cas où la réponse ne serait pas dans les noms locaux. Ce dnsmasq est donc configuré pour interroger mes différentes instances DNS (chatillon., .virt, etc…). Ce mode de configuration a pour effet d'éviter les double couplage (dnsmasq 1 pointe vers dnsmasq 2 et vice-versa…).
Depuis, tout est revenu à la normale…
Je suis quand même curieux de savoir s'il est possible de configurer dnsmasq pour qu'il évite de demander à la terre entière pour un domaine qu'il est sensé gérer… Typiquement, s'il n'a pas l'a réponse pour un_nom.virt.mydomain.net, c'est que ce nom n'existe pas, il répond et point barre. Le fonctionnement actuel est le suivant :
- on demande pwet.virt.mydomain.net
- si je trouve en local, je répond le résultat
- si je n'ai pas en local, je demande à google (8.8.8.8)
- si google me donne une réponse, je transmet, sinon je renvoi une réponse négative.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.