[technique] lxc.network.type = phys

Emmanuel Thierry ml at sekil.fr
Mer 1 Oct 12:45:52 CEST 2014 

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 utmp
>>> lxc-start 1412157298.238 DEBUG    lxc_utmp - utmp handler - run level is N/3
>>> lxc-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 = frp2007cu
>>>> lxc.network.type = phys
>>>> lxc.network.flags = up
>>>> lxc.network.link = eth1
>>>> lxc.network.ipv4 = 10.170.2.187/28
>>>> lxc.network.ipv4.gateway = 10.170.2.190
>>>> lxc.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 l
>>>> 1: 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:00
>>>> 2: 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:ff
>>>> 3: 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:ff
>>>> 4: 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 l
>>>> 1: 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:00
>>>> 2: 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:ff
>>>> 4: 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/c3ee775c/attachment.htm>

Plus d'informations sur la liste de diffusion technique