[technique] lxc.network.type = phys

Mer 1 Oct 12:26:22 CEST 2014

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 ?

Joris

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/c6b42521/attachment.htm>