[technique] lxc.network.type = phys

Joris Michaux joris.michaux at gmail.com
Mer 1 Oct 14:50:12 CEST 2014 

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.

Merci pour ton temps en tout cas.

Joris

Le 1 octobre 2014 12:45, Emmanuel Thierry <ml at sekil.fr> a écrit :

>
> Le 1 oct. 2014 à 12:26, Joris Michaux a écrit :
>
> Kernel version : 3.2.0-4-amd64
> LXC version : 0.8.0-rc1
>
> Ces deux versions sont les mêmes sur les 5 machines. Fonctionnelles sur 4
> d'entre elles.
>
> 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.
>
> 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 ?
>
>
> On sait jamais, tu peux regarder en revenant au noyau précédent.
> 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.
>
> Manu
>
>
> Le 1 octobre 2014 12:15, Emmanuel Thierry <ml at sekil.fr> a écrit :
>
>> Quel noyau ?
>> Est-ce que ça marche si tu changes de noyau ?
>>
>> Manu
>>
>> Le 1 oct. 2014 à 12:05, Joris Michaux a écrit :
>>
>> 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.
>>
>> Joris
>>
>> Le 1 octobre 2014 12:03, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>
>>> Si tu le lances et que tu fais un lxc-console dessus, qu'est ce que ça
>>> te donne ?
>>>
>>> Manu
>>>
>>> Le 1 oct. 2014 à 11:58, Joris Michaux a écrit :
>>>
>>> Les logs LXC en DEBUG ne donnent aucune ERROR, juste en boucle :
>>>
>>>
>>> *lxc-start 1412157298.238 DEBUG    lxc_utmp - got inotify event 2 for
>>> utmplxc-start 1412157298.238 DEBUG    lxc_utmp - utmp handler - run level
>>> is N/3lxc-start 1412157298.238 DEBUG    lxc_utmp - Container running*
>>>
>>> DMESG n'est pas beaucoup plus bavard...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *[64378.699884] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow
>>> Control: None[64378.702417] ADDRCONF(NETDEV_UP): eth1: link is not
>>> ready[64378.703358] ADDRCONF(NETDEV_CHANGE): eth1: link becomes
>>> ready[64389.514779] eth1: no IPv6 routers present[64947.736211] e1000: eth1
>>> NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None[64947.738740]
>>> ADDRCONF(NETDEV_UP): eth1: link is not ready[64947.739686]
>>> ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready[64958.343388] eth1: no
>>> IPv6 routers present*
>>>
>>> Joris
>>>
>>> Le 1 octobre 2014 11:48, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>>
>>>>
>>>> Des logs lxc ou dmesg lorsque le container est lancé ?
>>>>
>>>> Manu
>>>>
>>>> Le 1 oct. 2014 à 11:45, Joris Michaux a écrit :
>>>>
>>>> J'ai oublié de préciser que quand les containers sont éteints, les 3
>>>> interfaces fonctionnent correctement. (ping, ssh...)
>>>>
>>>> C'est à l'allumage des containers que le réseau tombe sur l'interface
>>>> concernée.
>>>>
>>>> Typiquement :
>>>>
>>>> *Container 1 :*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *lxc.utsname = frp2007culxc.network.type = physlxc.network.flags =
>>>> uplxc.network.link = eth1lxc.network.ipv4 = 10.170.2.187/28
>>>> <http://10.170.2.187/28>lxc.network.ipv4.gateway =
>>>> 10.170.2.190lxc.network.hwaddr = 00:1E:01:61:5B:86*
>>>>
>>>> eth1 cesse de fonctionner lorsqu'elle est mappée à l'allumage du
>>>> container. (du mode "phys")
>>>>
>>>> *Les commandes avant allumage du container :*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *root at frp1007cu:/var/run/network# ip l1: lo: <LOOPBACK,UP,LOWER_UP> mtu
>>>> 16436 qdisc noqueue state UNKNOWN mode DEFAULT     link/loopback
>>>> 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0:
>>>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
>>>> DEFAULT qlen 1000    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff3:
>>>> eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
>>>> mode DEFAULT qlen 1000    link/ether 00:1e:01:61:5b:86 brd
>>>> ff:ff:ff:ff:ff:ff4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
>>>> pfifo_fast state UP mode DEFAULT qlen 1000*
>>>>     link/ether 00:1e:fd:d8:a3:44 brd ff:ff:ff:ff:ff:ff
>>>>
>>>> *Après :*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *root at frp1007cu:/var/run/network# ip l1: lo: <LOOPBACK,UP,LOWER_UP> mtu
>>>> 16436 qdisc noqueue state UNKNOWN mode DEFAULT     link/loopback
>>>> 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0:
>>>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
>>>> DEFAULT qlen 1000    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff4:
>>>> eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
>>>> mode DEFAULT qlen 1000    link/ether 00:1e:fd:d8:a3:44 brd
>>>> ff:ff:ff:ff:ff:ff*
>>>>
>>>> Ce comportement me parait normal, et est confirmé sur les autres hosts
>>>> de LXC.
>>>>
>>>> Joris
>>>>
>>>> Le 1 octobre 2014 11:34, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>>>
>>>>>
>>>>> Le 1 oct. 2014 à 11:28, Joris Michaux a écrit :
>>>>>
>>>>> Manu,
>>>>>
>>>>> 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.
>>>>>
>>>>> # ip netns et ip netns list ne revoient rien.
>>>>>
>>>>>
>>>>> 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é.
>>>>> 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.
>>>>>
>>>>> Que donne un simple :
>>>>> # ip l
>>>>>
>>>>> Par ailleurs, tu dois vérifier que les interfaces sont bien
>>>>> initialisées dans le dmesg :
>>>>> # dmesg
>>>>>
>>>>> Manu
>>>>>
>>>>>
>>>>> Aucune iptables en place sur le host (ni le fonctionnel, ni l'autre).
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Merci !
>>>>>
>>>>> Joris
>>>>>
>>>>> Le 1 octobre 2014 11:11, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>>>>
>>>>>> Bonjour,
>>>>>>
>>>>>> As-tu redémarré les container ou bien le problème a-t-il eu lieu
>>>>>> durant leur exécution ?
>>>>>>
>>>>>> Peux-tu exécuter les commandes suivantes ?
>>>>>> # ip netns
>>>>>> (pour chaque entrée de la liste => ${ns})
>>>>>> # ip netns exec ${ns} ip l
>>>>>> # ip netns exec ${ns} ip a
>>>>>> # ip netns exec ${ns} ip r
>>>>>> # ip netns exec ${ns} ip -6 r
>>>>>> (et toute autre information utile comme les règles netfilter ou
>>>>>> consors)
>>>>>>
>>>>>> Manu
>>>>>>
>>>>>> Le 1 oct. 2014 à 11:05, Joris Michaux a écrit :
>>>>>>
>>>>>> Bonjour à tous,
>>>>>>
>>>>>> Je vous écrit du fond de mon trou, je creuse depuis hier, et bientôt
>>>>>> je ne pourrai plus sortir...
>>>>>>
>>>>>> *Contexte : *
>>>>>> - 1 machine Debian 7 avec 3 interfaces :
>>>>>>   |_ eth0 = 10.170.2.189
>>>>>>   |_ eth1 = 10.170.2.187
>>>>>>   |_ eth2 = 10.170.2.185
>>>>>> - Rôle de la machine : héberger 2 containers LXC intégrant chacun un
>>>>>> Apache
>>>>>> - Configuration network des LXC : lxc.network.type = phys
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> *Mon problème :*
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> *Dernière chance :*
>>>>>> J'ai créé un nouveau container sur ladite machine, et même tout neuf,
>>>>>> il n'a pas de réseau.
>>>>>>
>>>>>>
>>>>>> *Ma demande :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 !*
>>>>>>
>>>>>> Merci à ceux qui me donneront quelques minutes !
>>>>>>
>>>>>> Joris M., un admin désemparé...
>>>>>> _______________________________________________
>>>>>> technique mailing list
>>>>>> technique at lists.tetaneutral.net
>>>>>> http://lists.tetaneutral.net/listinfo/technique
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20141001/a7f50b31/attachment.htm>

Plus d'informations sur la liste de diffusion technique