<p dir="ltr">Bonjour à tous,</p>
<p dir="ltr">Il a fallut remonter (non sans mal) au niveau des ESX pour soutirer l'information à SFR : les incidents font suite à chaque fois à la migration DRS des VM. Nos machines ont été exclues du DRS et des investigations sont en cour côté SFR.</p>
<p dir="ltr">Attention donc si vous êtes utilisateurs de LXC over ESX...</p>
<p dir="ltr">À suivre.</p>
<p dir="ltr">Merci pour ceux qui ont prit du temps pour moi.</p>
<p dir="ltr">Joris ;)</p>
<div class="gmail_quote">Le 6 oct. 2014 15:35, "Joris Michaux" <<a href="mailto:joris.michaux@gmail.com">joris.michaux@gmail.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Bonjour à tous,<br><br>C'est lundi ! Et le lundi, c'est cauchemars !<br><br></div>Le problème vient de survenir sur 2 machines en simultané !<br><br></div>Je relance une batterie de tests, mais ça ne donne toujours rien... Personne n'a eu d'illumination ?<br><br>Le backup d'une des deux machines est en court, je garde l'autre pour expérimenter...<br><br></div>Joris<br></div><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 17:31, Joris Michaux <span dir="ltr"><<a href="mailto:joris.michaux@gmail.com" target="_blank">joris.michaux@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Bon, la restauration au 26 septembre a tout remis en ordre. J'ai demandé une copie de la VM cassée, et je vais mettre à jour les paquets un a un pour voir si quelque chose fait planter le truc... C'est incompréhensible.<br><br>L'update que j'ai effectuée le 27 a concerné :<br><pre>  acpi-support-base (0.140-5+deb7u2 => 0.140-5+deb7u3)
  apt (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  apt-utils (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  bash (4.2+dfsg-0.1 => 4.2+dfsg-0.1+deb7u3)
  bind9-host (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  curl (7.26.0-1+wheezy9 => 7.26.0-1+wheezy10)
  dnsutils (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  file (5.11-2+deb7u3 => 5.11-2+deb7u5)
  gnupg (1.4.12-7+deb7u4 => 1.4.12-7+deb7u6)
  gpgv (1.4.12-7+deb7u4 => 1.4.12-7+deb7u6)
  host (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libapt-inst1.5 (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  libapt-pkg4.12 (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  libbind9-80 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libcurl3 (7.26.0-1+wheezy9 => 7.26.0-1+wheezy10)
  libdns88 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libisc84 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libisccc80 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libisccfg82 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  liblwres80 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libmagic1 (5.11-2+deb7u3 => 5.11-2+deb7u5)
  procmail (3.22-20 => 3.22-20+deb7u1)<br><br></pre>Mais elle a été faite sur l'ensemble des 5 machines, je ne vois pas pourquoi elle aurait impacté qu'une des 5...<br><br></div>À suivre !<br><br>Merci pour ton aide en tout cas.<br><br></div>Joris<br></div><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 14:50, Joris Michaux <span dir="ltr"><<a href="mailto:joris.michaux@gmail.com" target="_blank">joris.michaux@gmail.com</a>></span> a écrit :<div><div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Impossible pour SFR de booter sur un noyau différent. On tente une injection d'un backup full du 26, avant l'upgrade et le reboot, espérons ancien noyau.<br><br></div>Merci pour ton temps en tout cas.<br><br></div>Joris<br></div><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 12:45, Emmanuel Thierry <span dir="ltr"><<a href="mailto:ml@sekil.fr" target="_blank">ml@sekil.fr</a>></span> a écrit :<div><div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>Le 1 oct. 2014 à 12:26, Joris Michaux a écrit :</div><span><br><blockquote type="cite"><div dir="ltr"><div><div><div>Kernel version : 3.2.0-4-amd64<br></div>LXC version : 0.8.0-rc1<br><br></div>Ces deux versions sont les mêmes sur les 5 machines. Fonctionnelles sur 4 d'entre elles.<br><br></div>La seule variante est : 3.2.57-3+deb7u1 contre 3.2.60-1+deb7u3, du au redémarrage d'une machine est pas de l'autre. Mais le problème était survenu avant le reboot.<br><br>Je n'ai pas accès à l'écran de boot de la machine ("administration" SFR...), est-ce que ce test pourrait être probant ? Malgré la faible différence ?<br><div></div><div><br></div></div></blockquote><div><br></div></span><div>On sait jamais, tu peux regarder en revenant au noyau précédent.</div><div>Sinon là je sèche, je manque un peu d'infos pour t'aider... Tu peux regarder du côté de la ML lxc-users.</div><div><br></div><div>Manu</div><div><div><br><blockquote type="cite"><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 12:15, Emmanuel Thierry <span dir="ltr"><<a href="mailto:ml@sekil.fr" target="_blank">ml@sekil.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Quel noyau ?<div>Est-ce que ça marche si tu changes de noyau ?</div><div><br></div><div>Manu</div><div><br><div><div>Le 1 oct. 2014 à 12:05, Joris Michaux a écrit :</div><div><div><br><blockquote type="cite"><div dir="ltr"><div>En lançant le container sans "-d" je suis en console dessus. Mon interface est bien là, mes services tournent, mais rien en sort, rien ne rentre.<br><br></div>Joris<br></div><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 12:03, Emmanuel Thierry <span dir="ltr"><<a href="mailto:ml@sekil.fr" target="_blank">ml@sekil.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Si tu le lances et que tu fais un lxc-console dessus, qu'est ce que ça te donne ?<div><br></div><div>Manu</div><div><br><div><div>Le 1 oct. 2014 à 11:58, Joris Michaux a écrit :</div><div><div><br><blockquote type="cite"><div dir="ltr"><div><div>Les logs LXC en DEBUG ne donnent aucune ERROR, juste en boucle :<br><i>lxc-start 1412157298.238 DEBUG    lxc_utmp - got inotify event 2 for utmp<br>lxc-start 1412157298.238 DEBUG    lxc_utmp - utmp handler - run level is N/3<br>lxc-start 1412157298.238 DEBUG    lxc_utmp - Container running</i><br><br></div>DMESG n'est pas beaucoup plus bavard...<br><i>[64378.699884] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None<br>[64378.702417] ADDRCONF(NETDEV_UP): eth1: link is not ready<br>[64378.703358] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready<br>[64389.514779] eth1: no IPv6 routers present<br>[64947.736211] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None<br>[64947.738740] ADDRCONF(NETDEV_UP): eth1: link is not ready<br>[64947.739686] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready<br>[64958.343388] eth1: no IPv6 routers present</i><br><br></div>Joris<br></div><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 11:48, Emmanuel Thierry <span dir="ltr"><<a href="mailto:ml@sekil.fr" target="_blank">ml@sekil.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div>Des logs lxc ou dmesg lorsque le container est lancé ?<div><br></div><div>Manu<br><div><br><div><div>Le 1 oct. 2014 à 11:45, Joris Michaux a écrit :</div><div><div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div>J'ai oublié de préciser que quand les containers sont éteints, les 3 interfaces fonctionnent correctement. (ping, ssh...)<br><br></div>C'est à l'allumage des containers que le réseau tombe sur l'interface concernée.<br><br>Typiquement :<br><br></div><u>Container 1 :</u><br><i>lxc.utsname = frp2007cu<br>lxc.network.type = phys<br>lxc.network.flags = up<br>lxc.network.link = eth1<br>lxc.network.ipv4 = <a href="http://10.170.2.187/28" target="_blank">10.170.2.187/28</a><br>lxc.network.ipv4.gateway = 10.170.2.190<br>lxc.network.hwaddr = 00:1E:01:61:5B:86</i><br><br></div>eth1 cesse de fonctionner lorsqu'elle est mappée à l'allumage du container. (du mode "phys")<br><br></div><u>Les commandes avant allumage du container :</u><br><i>root@frp1007cu:/var/run/network# ip l<br>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT <br>    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000<br>    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff<br>3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000<br>    link/ether 00:1e:01:61:5b:86 brd ff:ff:ff:ff:ff:ff<br>4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000</i><br>    link/ether 00:1e:fd:d8:a3:44 brd ff:ff:ff:ff:ff:ff<br><br></div><u>Après :</u><br><i>root@frp1007cu:/var/run/network# ip l<br>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT <br>    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000<br>    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff<br>4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000<br>    link/ether 00:1e:fd:d8:a3:44 brd ff:ff:ff:ff:ff:ff</i><br><br></div>Ce comportement me parait normal, et est confirmé sur les autres hosts de LXC.<br><br>Joris<br></div><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 11:34, Emmanuel Thierry <span dir="ltr"><<a href="mailto:ml@sekil.fr" target="_blank">ml@sekil.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>Le 1 oct. 2014 à 11:28, Joris Michaux a écrit :</div><span><br><blockquote type="cite"><div dir="ltr"><div><div><div><div>Manu,<br><br></div><div>Le problème est survenu à 
7h12 hier. Heure à laquelle le trafic a balancé sur le deuxième serveur 
fonctionnel. Sans redémarrage. Depuis j'ai redémarré le container 
plusieurs fois, et même une fois la machine.<br></div><div><br></div># ip netns et ip netns list ne revoient rien.<br></div></div></div></div></blockquote><div><br></div></span><div>Il faut commencer par ça. S'il n'y a rien c'est que le problème vient de là vu que la création des namespace réseau a échoué.</div><div>Du coup les interfaces doivent encore exister sur le namespace de l'hôte, si ce n'est pas le cas c'est que le problème vient du matériel ou des drivers ethernet.</div><div><br></div><div>Que donne un simple :</div><div># ip l</div><div><br></div><div>Par ailleurs, tu dois vérifier que les interfaces sont bien initialisées dans le dmesg :</div><div># dmesg</div><div><br></div><div>Manu</div><div><div><br><blockquote type="cite"><div dir="ltr"><div><div><div><br></div>Aucune iptables en place sur le host (ni le fonctionnel, ni l'autre).</div></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div><div><br></div>J'ai
 des iptables sur deux hosts hébergeant les Reverse-Proxy Nginx, mais 
pas sur les deux hosts hébergeant les webservers. Je tape sur le bon via
 des tunnels ssl (stunnel4). Le fait qu'ils aient chacun une interface 
dédiée m'évite les iptables à ce niveau.<br><br></div><div>PS : la 
machine à problèmes a une sœur jumelle fonctionnelle sur laquelle je 
peux comparer les configurations, ce que je n'arrête pas de faire depuis
 hier.<br></div><div><br></div><div>Merci !<br></div><div><br></div>Joris</div><div class="gmail_extra"><br><div class="gmail_quote">Le 1 octobre 2014 11:11, Emmanuel Thierry <span dir="ltr"><<a href="mailto:ml@sekil.fr" target="_blank">ml@sekil.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Bonjour,<div><br></div><div>As-tu redémarré les container ou bien le problème a-t-il eu lieu durant leur exécution ?</div><div><br></div><div>Peux-tu exécuter les commandes suivantes ?</div><div># ip netns</div><div>(pour chaque entrée de la liste => ${ns})</div><div># ip netns exec ${ns} ip l</div># ip netns exec ${ns} ip a<div># ip netns exec ${ns} ip r</div><div># ip netns exec ${ns} ip -6 r</div><div>(et toute autre information utile comme les règles netfilter ou consors)</div><div><br></div><div>Manu</div><div><br><div><div><div>Le 1 oct. 2014 à 11:05, Joris Michaux a écrit :</div><br><blockquote type="cite"><div><div><div dir="ltr"><div><div><div><div><div><div><div>Bonjour à tous,<br><br></div>Je vous écrit du fond de mon trou, je creuse depuis hier, et bientôt je ne pourrai plus sortir...<br><br></div><u>Contexte : </u><br></div>- 1 machine Debian 7 avec 3 interfaces :<br></div>  |_ eth0 = 10.170.2.189<br></div>  |_ eth1 = 10.170.2.187<br></div>  |_ eth2 = 10.170.2.185<br></div><div>- Rôle de la machine : héberger 2 containers LXC intégrant chacun un Apache<br></div><div>- Configuration network des LXC : lxc.network.type = phys<br><br></div><div>Le comportement du type "phys" de LXC est que l'interface ciblée est "aspirée" par le LXC (elle disparaît du ifconfig sur le host), et le container en bénéficie sans autre configuration.<br><br></div><div><u>Mon problème :</u><br></div><div>J'utilise ce mode de fonctionnement sur 5 machines en prod depuis 8 mois, sans aucun problème. Depuis hier matin, les 2 LXC d'une des 5 machines ont perdu le réseau, alors que les 8 autres continuent de fonctionner. Les configurations sont pupettisées, je ne vois pas comment elles auraient pu casser, sur une seule machine.<br><br></div><div>Depuis hier je compare les fichiers de configuration des hôtes, des containers, les iptables, les routes, les tables arp... Je ne vois pas où est le problème.<br><br></div><div><u>Dernière chance :</u><br></div><div>J'ai créé un nouveau container sur ladite machine, et même tout neuf, il n'a pas de réseau.<br><br></div><div><b><u>Ma demande :</u><br>Que vous ayez ou non déjà utilisé LXC, si vous avez n'importe quelle question bête à poser sur la configuration, ça peut m'éclairer sur un truc que je rate, et je vous en serai vraiment reconnaissant !</b><br><br></div><div>Merci à ceux qui me donneront quelques minutes !<br><br></div><div>Joris M., un admin désemparé...<br></div></div></div></div>
_______________________________________________<br>technique mailing list<br><a href="mailto:technique@lists.tetaneutral.net" target="_blank">technique@lists.tetaneutral.net</a><br><a href="http://lists.tetaneutral.net/listinfo/technique" target="_blank">http://lists.tetaneutral.net/listinfo/technique</a><br></blockquote></div><br></div></div></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div></blockquote></div></div></div><br></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>
</blockquote></div>