*** dxiri has joined #openstack-ansible | 00:04 | |
*** dxiri has quit IRC | 00:08 | |
*** dxiri has joined #openstack-ansible | 00:08 | |
*** smatzek has joined #openstack-ansible | 00:17 | |
*** dxiri has quit IRC | 00:18 | |
*** smatzek has quit IRC | 00:22 | |
*** dxiri has joined #openstack-ansible | 00:36 | |
*** dxiri has quit IRC | 00:41 | |
*** dxiri has joined #openstack-ansible | 00:51 | |
*** markvoelker has joined #openstack-ansible | 00:51 | |
*** dxiri has quit IRC | 00:55 | |
*** dxiri has joined #openstack-ansible | 01:05 | |
*** dxiri has quit IRC | 01:10 | |
*** dxiri has joined #openstack-ansible | 01:20 | |
*** markvoelker has quit IRC | 01:24 | |
*** dxiri has quit IRC | 01:24 | |
*** galstrom_zzz is now known as galstrom | 01:32 | |
*** dxiri has joined #openstack-ansible | 01:34 | |
*** dxiri has quit IRC | 01:39 | |
*** smatzek has joined #openstack-ansible | 01:48 | |
*** dxiri has joined #openstack-ansible | 01:48 | |
*** smatzek has quit IRC | 01:52 | |
*** dxiri has quit IRC | 01:53 | |
*** dxiri has joined #openstack-ansible | 02:03 | |
*** galstrom is now known as galstrom_zzz | 02:04 | |
*** dxiri has quit IRC | 02:08 | |
*** galstrom_zzz is now known as galstrom | 02:10 | |
*** dxiri has joined #openstack-ansible | 02:22 | |
*** dxiri has quit IRC | 02:26 | |
*** jwitko has quit IRC | 02:29 | |
*** jwitko has joined #openstack-ansible | 02:29 | |
*** askb has quit IRC | 02:30 | |
*** dxiri has joined #openstack-ansible | 02:36 | |
*** dxiri has quit IRC | 02:38 | |
*** dxiri has joined #openstack-ansible | 02:38 | |
*** sxc731 has joined #openstack-ansible | 02:52 | |
*** sxc731 has left #openstack-ansible | 02:53 | |
*** dxiri has quit IRC | 02:54 | |
*** dave-mcc_ has joined #openstack-ansible | 02:58 | |
*** dave-mccowan has quit IRC | 03:00 | |
*** galstrom is now known as galstrom_zzz | 03:05 | |
*** dxiri has joined #openstack-ansible | 03:05 | |
*** germs1 has joined #openstack-ansible | 03:19 | |
*** germs has quit IRC | 03:19 | |
*** markvoelker has joined #openstack-ansible | 03:22 | |
*** germs has joined #openstack-ansible | 03:23 | |
*** germs1 has quit IRC | 03:26 | |
*** dave-mcc_ has quit IRC | 03:36 | |
*** sc68cal has quit IRC | 03:45 | |
*** sc68cal has joined #openstack-ansible | 03:55 | |
*** markvoelker has quit IRC | 03:55 | |
*** germs has quit IRC | 04:06 | |
*** masber has joined #openstack-ansible | 04:11 | |
*** smatzek has joined #openstack-ansible | 05:50 | |
*** markvoelker has joined #openstack-ansible | 05:52 | |
*** smatzek has quit IRC | 05:55 | |
*** sxc731 has joined #openstack-ansible | 05:55 | |
*** sxc731 has quit IRC | 05:56 | |
*** sxc731 has joined #openstack-ansible | 05:56 | |
*** sxc731 has quit IRC | 05:57 | |
*** sxc731 has joined #openstack-ansible | 05:58 | |
*** sxc731 has left #openstack-ansible | 05:59 | |
*** snowman4839 has joined #openstack-ansible | 06:16 | |
snowman4839 | does anyone understand how the veth pairs in the neutron-agents container work? I've been trying to understand how all the linux bridges are hooked up and nothing is quite making sense | 06:17 |
---|---|---|
snowman4839 | like many of the veth indexes don't have matching interfaces so I don't know where the traffic is going yet it still all works? | 06:19 |
snowman4839 | I've check all the network namespaces and still nothing | 06:20 |
*** markvoelker has quit IRC | 06:26 | |
*** armaan has quit IRC | 06:27 | |
*** hachi_ has joined #openstack-ansible | 06:36 | |
*** DanyC has joined #openstack-ansible | 06:38 | |
*** DanyC_ has joined #openstack-ansible | 06:46 | |
*** DanyC has quit IRC | 06:49 | |
SamYaple | snowman4839: are you refereing to general openstack networking? or OSA host <-> container veth pairs? | 06:54 |
snowman4839 | well both. I'm just playing with an AIO OSA install atm. When I look at the veth indexes of all of the container interfaces on the host, there is only one interface with that veth index available on the host | 06:56 |
SamYaple | snowman4839: if its openstack networking, check https://docs.openstack.org/ocata/networking-guide/deploy-lb.html | 06:56 |
snowman4839 | I've read most of it already but I'll give it another look. | 06:57 |
SamYaple | the host <-> container networking is pretty straight forward. nothing really special there, so without a more specific question i probably wont be of much help | 06:57 |
SamYaple | there are no diagrams that i know of showing pictures for that part | 06:57 |
snowman4839 | so veth interfaces are created in pairs correct? | 06:58 |
SamYaple | yup | 06:58 |
snowman4839 | so my question is when I look at all of the interfaces on the host, more specifically the container<->host interfaces, why don't I see each half of the veth pair? | 06:58 |
snowman4839 | for example, 83: eca7b9ed_eth0@if82 is the host half of the veth0 pair corresponding to the eth0 interface inside my neutron-agents container | 06:59 |
SamYaple | ah. right | 06:59 |
SamYaple | so when a veth pair goes into a network namespace that interface doesnt align the same way if i recall | 07:00 |
snowman4839 | the @if82 being the veth index. I don't see another interface tagged with the 82 index so I'm not sure how I'm supposed to know where the other half of that veth traffic goes | 07:00 |
SamYaple | there are various oneliners ive used to link those two together | 07:00 |
SamYaple | but it gets complicated | 07:00 |
snowman4839 | well on my host when running ip netns, it's empty | 07:00 |
SamYaple | the kernel doesnt maintain a list of network namespaces | 07:01 |
SamYaple | ip netns creates a network namespace mount in /run/netns | 07:01 |
SamYaple | lxc netowrking creates a mount point elsewhere | 07:01 |
SamYaple | i forget where | 07:01 |
snowman4839 | yes but running ip netns is a way of checking if there are namespaces create correct? | 07:01 |
SamYaple | no | 07:01 |
SamYaple | thats a way to see namespaces created by iproute2 | 07:02 |
SamYaple | i mean something else could create one in the same place too and iproute2 would see it | 07:02 |
SamYaple | but its just walking /run/netns to see namepsaces that exist | 07:02 |
snowman4839 | that I didn't know | 07:02 |
snowman4839 | but regardless, what would be the point of having a veth interface without a corresponding interface on the same index? | 07:03 |
SamYaple | yea the kernel doesnt have a list of namespaces, pid/user/net or otherwise | 07:03 |
SamYaple | the other side exists, in the container net namespace | 07:03 |
SamYaple | the kernel passes traffic between the two sides | 07:03 |
snowman4839 | would they share an index or is the other side implicit/hidden or something? | 07:04 |
snowman4839 | my host and my neutron container share no veth indexes on any container in any network namespace | 07:04 |
SamYaple | well they dont *share* an index, but one side has the index of its peer that you can find | 07:04 |
SamYaple | i think you have to crawl /proc or /sys for it, its been a few years since ive needed to do it | 07:05 |
snowman4839 | yeah its in /sys/class/net | 07:05 |
SamYaple | ethtool -S <veth> | 07:06 |
snowman4839 | so here's the deal, can I just send you a pastebin real quick? | 07:06 |
snowman4839 | thanks for helping btw | 07:06 |
SamYaple | that will give you peer_ifindex | 07:06 |
SamYaple | you can send a pastebin sure | 07:07 |
snowman4839 | https://pastebin.com/Hb7z8rbS | 07:07 |
SamYaple | anyway, ethtool will tell you the peer index, and then running the same command from the container interface will match the index | 07:07 |
snowman4839 | so at the top, those are the interfaces in my neutron container and their if# (indexes). at the bottom, those the associated host interfaces for that container | 07:07 |
SamYaple | the part after @ i dont think is garunteed to be the same | 07:08 |
SamYaple | ip defeintely doesnt expose the information you are looking for | 07:08 |
snowman4839 | it is, I've checked about 40 times today. I've been staring at this for about 8 hours | 07:08 |
snowman4839 | but the indicies are off by one inside and outside the container | 07:09 |
SamYaple | there are off by one because they are garaunteed to be the same | 07:09 |
SamYaple | again its been a few years since ive had to dig this deep, but i know you cant rely on it | 07:09 |
SamYaple | it renumbers all the interfaces once they are in the mount namespace | 07:10 |
SamYaple | start using that ethtool command from above to track it | 07:10 |
snowman4839 | wait they ARE off by one because they ARE the same? | 07:10 |
SamYaple | no they are coincidentally off by one | 07:10 |
SamYaple | proabbly due to the way the container is created | 07:11 |
snowman4839 | https://pastebin.com/KZG9xF9N there's using ethtool, they're the same indicies | 07:11 |
snowman4839 | so I'm confused, does lxc do some auto veth pair index fixing or something? I'm assuming and index is like a vlan tag, they have to be the same to talk to each other? | 07:12 |
SamYaple | im condused, how is 31 the same index as 32? | 07:12 |
snowman4839 | I'm sorry | 07:13 |
SamYaple | 31 and 32 appear to be peers here, yes | 07:13 |
snowman4839 | same as before when I used ip -d l | 07:13 |
snowman4839 | not 31 is the same as 32. I know that was confusing | 07:13 |
*** armaan has joined #openstack-ansible | 07:13 | |
snowman4839 | but I thought the numbers had to be the same for them to be peers | 07:13 |
SamYaple | if you are refering to the part after @ then no | 07:14 |
SamYaple | the peer index tells the kerenl were to forward the traffic | 07:14 |
SamYaple | the name doesnt really matter | 07:14 |
snowman4839 | REALLY? | 07:14 |
snowman4839 | oh I know the name of the interface didn't matter. I thought matching perr_ifindex numbers were what linked together interfaces | 07:15 |
SamYaple | yes, thats all that matters. | 07:15 |
SamYaple | it sounds like we are on the same page there... so what is the question? | 07:15 |
snowman4839 | but that goes back to my original question, how can the interface outside the container and the one inside be peers if their peer_ifindex is one off? | 07:16 |
SamYaple | ... each interface has a unique index | 07:16 |
SamYaple | one side of the peer is 31, the other side is 32 | 07:16 |
SamYaple | each side knows about the other one | 07:16 |
SamYaple | this isn't an off by one, that is the *peer* interface index | 07:17 |
SamYaple | 31 knows its *peer* is 32 | 07:17 |
SamYaple | 32 knows its *peer* is 31 | 07:17 |
snowman4839 | so are those peerings written in the /run/netns you were talking about earlier? | 07:18 |
SamYaple | no | 07:18 |
SamYaple | the peering is part of the veth pair when its created | 07:18 |
snowman4839 | lol sorry I'm being so slow | 07:18 |
SamYaple | no problem, just think | 07:18 |
SamYaple | kernel creates veth pair | 07:18 |
SamYaple | thats two interefaces | 07:18 |
SamYaple | the structure for the kernel to keep track of thse interfaces has a place for the peer | 07:18 |
SamYaple | the two are always linked, knowing about the other one | 07:19 |
SamYaple | but they are two unique interfaces | 07:19 |
SamYaple | traffic comes in one, kernel looks up the peer, traffic does out the peer | 07:19 |
SamYaple | goes* | 07:19 |
snowman4839 | so is there a way to find the peer of a device if they are named abiguously? | 07:19 |
SamYaple | ethtool | 07:19 |
SamYaple | you posted all of this output | 07:20 |
SamYaple | interface 31 is telling you its peer is 32 | 07:20 |
snowman4839 | OH MY GOD IM SO F*IN STUPID | 07:20 |
snowman4839 | WOW | 07:20 |
snowman4839 | WOW | 07:20 |
snowman4839 | just clicked | 07:20 |
SamYaple | yea i was trying to highlight the word *peer* | 07:21 |
SamYaple | ive been there man | 07:21 |
snowman4839 | I've seriously been tcpdumping and lookin at iptables and jumpin in and out of network namespaces and stuff for about 10 hours | 07:21 |
SamYaple | yea man. ive totally been there | 07:21 |
snowman4839 | and I just had to notice that the interface number was not the same as its peer number | 07:22 |
snowman4839 | omfg | 07:22 |
snowman4839 | jesus christ | 07:22 |
SamYaple | yep. :) | 07:22 |
SamYaple | thanks for taking me back a few years | 07:22 |
snowman4839 | well thank you for sitting through that | 07:22 |
snowman4839 | lol no problem | 07:22 |
SamYaple | anytime :) glad it all clicked | 07:22 |
snowman4839 | I'm trying to understand neutron more in depth for my multinode deployment and this has been a bugger. should've come here earlier lol | 07:23 |
*** markvoelker has joined #openstack-ansible | 07:23 | |
snowman4839 | seriously thank you | 07:23 |
snowman4839 | actually, one more thing. | 07:23 |
SamYaple | NO NO NO | 07:23 |
SamYaple | im goign to bed! | 07:23 |
snowman4839 | lol it should be easy I swear | 07:23 |
SamYaple | shoot :) | 07:24 |
snowman4839 | can you only create veth pairs with lxc containers because they share the kernel unlike full kvm/qemu style virt? | 07:24 |
SamYaple | yea | 07:24 |
snowman4839 | or does full virtualization also use veth | 07:24 |
SamYaple | though be careful with that, virtio devices are very similiar to veth pairs... just more memcpy'ing | 07:25 |
snowman4839 | gotcha. so does full virt use tun/tap or something? | 07:25 |
snowman4839 | that was my last quesiton I swear :) | 07:25 |
SamYaple | basically the virtio stuff is sharing memory, so you write something to memory in the vm and the kernel on the host can access that directly, rather than some other copmlicated full emulation method | 07:25 |
SamYaple | more or less, that gets a bit hairy though | 07:26 |
snowman4839 | lol gotcha. I'll leave that to google. thank you ver much sir. you're a godsend | 07:26 |
SamYaple | thats what they all say | 07:26 |
SamYaple | until they get to know me :( | 07:27 |
snowman4839 | don't say that lol | 07:27 |
snowman4839 | you helped a stranger with an obscure question at 2am | 07:27 |
SamYaple | something about only being interested in myself and not listening. i dont know, i wasnt really paying attention | 07:27 |
snowman4839 | A+ person to me | 07:27 |
snowman4839 | hahahahaha | 07:27 |
snowman4839 | yall have a good night | 07:28 |
SamYaple | night | 07:28 |
*** sxc731 has joined #openstack-ansible | 07:46 | |
*** sxc731 has left #openstack-ansible | 07:48 | |
*** markvoelker has quit IRC | 07:56 | |
*** hachi_ has quit IRC | 08:07 | |
*** armaan has quit IRC | 08:21 | |
*** sxc731 has joined #openstack-ansible | 08:23 | |
*** vishwana_ has joined #openstack-ansible | 08:48 | |
*** vishwanathj has quit IRC | 08:49 | |
*** markvoelker has joined #openstack-ansible | 08:53 | |
*** armaan has joined #openstack-ansible | 08:55 | |
*** sxc731 has quit IRC | 09:13 | |
*** markvoelker has quit IRC | 09:26 | |
*** hachi_ has joined #openstack-ansible | 09:43 | |
openstackgerrit | Markos Chandras (hwoarang) proposed openstack/openstack-ansible-lxc_hosts master: tasks: lxc_cache_preparation.yml: Log cache preparation command output https://review.openstack.org/510339 | 09:47 |
openstackgerrit | Markos Chandras (hwoarang) proposed openstack/openstack-ansible-lxc_hosts master: tasks: lxc_cache_preparation: Log cache preparation command output https://review.openstack.org/510339 | 09:48 |
*** smatzek has joined #openstack-ansible | 09:52 | |
*** smatzek has quit IRC | 09:56 | |
*** yifei has joined #openstack-ansible | 10:08 | |
*** yifei has quit IRC | 10:12 | |
*** masber has quit IRC | 10:14 | |
*** markvoelker has joined #openstack-ansible | 10:24 | |
*** drifterza has joined #openstack-ansible | 10:25 | |
*** pbandark has joined #openstack-ansible | 10:28 | |
*** sxc731 has joined #openstack-ansible | 10:29 | |
*** pbandark has quit IRC | 10:30 | |
*** drifterza1 has joined #openstack-ansible | 10:30 | |
*** drifterza has quit IRC | 10:31 | |
*** pbandark has joined #openstack-ansible | 10:32 | |
*** drifterza has joined #openstack-ansible | 10:33 | |
*** drifterza1 has quit IRC | 10:35 | |
*** hachi__ has joined #openstack-ansible | 10:38 | |
*** hachi_ has quit IRC | 10:38 | |
*** hachi__ has quit IRC | 10:57 | |
*** markvoelker has quit IRC | 10:57 | |
*** drifterza has quit IRC | 11:20 | |
*** drifterza has joined #openstack-ansible | 11:20 | |
*** drifterza has quit IRC | 11:24 | |
*** drifterza has joined #openstack-ansible | 11:45 | |
*** sxc731 has quit IRC | 11:45 | |
*** masber has joined #openstack-ansible | 11:51 | |
*** markvoelker has joined #openstack-ansible | 11:54 | |
*** markvoelker has quit IRC | 12:27 | |
*** drifterza has quit IRC | 12:53 | |
*** drifterza has joined #openstack-ansible | 12:56 | |
*** drifterza1 has joined #openstack-ansible | 12:56 | |
*** drifterza has quit IRC | 13:00 | |
*** hachi_ has joined #openstack-ansible | 13:11 | |
*** armaan has quit IRC | 13:53 | |
*** hachi_ has quit IRC | 14:16 | |
*** hachi_ has joined #openstack-ansible | 14:16 | |
*** gunix has quit IRC | 14:21 | |
*** markvoelker has joined #openstack-ansible | 14:24 | |
*** markvoelker has quit IRC | 14:58 | |
*** dxiri has quit IRC | 15:31 | |
*** dxiri has joined #openstack-ansible | 15:38 | |
*** hachi_ has quit IRC | 15:47 | |
*** ivve has quit IRC | 15:54 | |
*** smatzek has joined #openstack-ansible | 15:54 | |
*** markvoelker has joined #openstack-ansible | 15:55 | |
*** smatzek has quit IRC | 15:59 | |
*** ivve has joined #openstack-ansible | 16:07 | |
*** drifterza1 has quit IRC | 16:20 | |
*** drifterza has joined #openstack-ansible | 16:22 | |
*** markvoelker has quit IRC | 16:27 | |
*** gouthamr has joined #openstack-ansible | 16:27 | |
*** mpranjic has quit IRC | 16:52 | |
*** pbandark has quit IRC | 16:53 | |
*** gouthamr_ has joined #openstack-ansible | 16:57 | |
*** gouthamr has quit IRC | 16:58 | |
*** markvoelker has joined #openstack-ansible | 17:24 | |
*** gunix has joined #openstack-ansible | 17:51 | |
*** markvoelker has quit IRC | 17:58 | |
*** hachi_ has joined #openstack-ansible | 18:25 | |
*** armaan has joined #openstack-ansible | 18:34 | |
*** armaan has quit IRC | 18:36 | |
*** jwitko has quit IRC | 18:39 | |
*** jwitko has joined #openstack-ansible | 18:39 | |
*** jwitko has quit IRC | 18:41 | |
*** jwitko has joined #openstack-ansible | 18:42 | |
*** jwitko has quit IRC | 18:43 | |
*** jwitko has joined #openstack-ansible | 18:43 | |
*** gouthamr_ has quit IRC | 18:47 | |
*** dxiri has quit IRC | 18:51 | |
*** pbandark has joined #openstack-ansible | 18:55 | |
*** markvoelker has joined #openstack-ansible | 18:56 | |
*** dxiri has joined #openstack-ansible | 19:07 | |
*** drifterza has quit IRC | 19:09 | |
*** dave-mccowan has joined #openstack-ansible | 19:11 | |
*** dave-mcc_ has joined #openstack-ansible | 19:16 | |
*** dave-mccowan has quit IRC | 19:19 | |
*** pbandark has quit IRC | 19:19 | |
*** markvoelker has quit IRC | 19:28 | |
*** smatzek has joined #openstack-ansible | 19:56 | |
*** dave-mcc_ has quit IRC | 19:59 | |
*** smatzek has quit IRC | 20:01 | |
*** DanyC_ has quit IRC | 20:01 | |
*** aaron has joined #openstack-ansible | 20:02 | |
*** aaron is now known as Guest49299 | 20:03 | |
*** galstrom_zzz is now known as galstrom | 20:16 | |
Guest49299 | Hey all, I am looking at the network-overview here: https://docs.openstack.org/project-deploy-guide/openstack-ansible/pike/overview-network-arch.html | 20:16 |
Guest49299 | I have 2 phy ports on 2 servers (1 controller, 1 compute) and not sure on the best/recommended way to create these 4 bridges on 2 phy interfaces.. any suggestions? | 20:17 |
Guest49299 | I was thinking this maybe a job for OVS? 2 bridges, 1 per interface and 1 port for each bridge? | 20:18 |
*** markvoelker has joined #openstack-ansible | 20:25 | |
asb47 | Hi all, I'm hoping to use a Xen hypervisor, but looking in defaults/main.yml in os_nova there doesn't seem to be a xen "nova_supported_virt_types". Other openstack resources suggest that it's supported, but I'd like to be able to use openstack-ansible as much as possible. Any suggestions? | 20:58 |
*** markvoelker has quit IRC | 20:58 | |
asb47 | Aiming to use Xen with libvirt | 20:59 |
*** DanyC has joined #openstack-ansible | 21:03 | |
*** DanyC has quit IRC | 21:07 | |
*** galstrom is now known as galstrom_zzz | 21:09 | |
*** dachary has left #openstack-ansible | 21:36 | |
*** threestrands has joined #openstack-ansible | 21:49 | |
*** hachi_ has quit IRC | 21:54 | |
*** xingchao has joined #openstack-ansible | 21:56 | |
*** markvoelker has joined #openstack-ansible | 21:56 | |
*** xingchao has quit IRC | 21:58 | |
*** DanyC has joined #openstack-ansible | 22:03 | |
*** asb47 has quit IRC | 22:07 | |
*** asb47 has joined #openstack-ansible | 22:07 | |
*** DanyC has quit IRC | 22:09 | |
*** Guest49299 has quit IRC | 22:09 | |
*** aaron has joined #openstack-ansible | 22:09 | |
*** aaron is now known as Guest6322 | 22:10 | |
*** dave-mccowan has joined #openstack-ansible | 22:22 | |
*** markvoelker has quit IRC | 22:29 | |
*** gouthamr has joined #openstack-ansible | 22:32 | |
*** askb has joined #openstack-ansible | 22:40 | |
*** askb has quit IRC | 22:44 | |
*** askb has joined #openstack-ansible | 22:45 | |
*** askb has quit IRC | 22:53 | |
*** askb has joined #openstack-ansible | 22:53 | |
*** markvoelker has joined #openstack-ansible | 22:54 | |
*** askb has quit IRC | 22:56 | |
*** xingchao has joined #openstack-ansible | 23:03 | |
*** dave-mccowan has quit IRC | 23:15 | |
*** Guest6322 has quit IRC | 23:19 | |
*** xingchao has quit IRC | 23:23 | |
*** askb has joined #openstack-ansible | 23:23 | |
*** askb has quit IRC | 23:27 | |
*** askb has joined #openstack-ansible | 23:28 | |
*** askb has quit IRC | 23:43 | |
*** pmannidi has joined #openstack-ansible | 23:48 | |
*** pbandark has joined #openstack-ansible | 23:52 | |
*** jwitko has quit IRC | 23:54 | |
*** jwitko has joined #openstack-ansible | 23:54 | |
*** smatzek has joined #openstack-ansible | 23:58 | |
*** xingchao has joined #openstack-ansible | 23:58 | |
*** xingchao has quit IRC | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!