[technique] lxc.network.type = phys

Mer 1 Oct 12:05:46 CEST 2014

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