On Tue, Feb 24, 2015 at 11:50 AM, Serge Hallyn <serge.hal...@ubuntu.com> wrote: > Quoting Fajar A. Nugraha (l...@fajar.net): >> On Wed, Feb 18, 2015 at 12:27 AM, Serge Hallyn <serge.hal...@ubuntu.com> >> wrote: >> > Quoting Fajar A. Nugraha (l...@fajar.net): >> >> # c1's veth name on host side >> >> auto v-c1-0 >> >> iface v-c1-0 inet static >> > >> > I'm probably just ignorant here, but - does this not cause 'ifup -a' to >> > fail when the containers are not up? >> >> ifup throws an error message, but still exit with code 0, so it should >> be safe. udev and network-interface service will kick in to >> automatically activate it when the interface becomes available (i.e. >> when the container is started) >> >> # ifup -a;echo $? >> Cannot find device "v-c1-0" >> Failed to bring up v-c1-0. >> 0 >> >> # ifup v-c1-0;echo $? >> Cannot find device "v-c1-0" >> Failed to bring up v-c1-0. >> 0 > > Agreed it sounds like a very useful setup. > > Any chance you would have time to write the needed extensions for > lxc-user-nic?
Not anytime immediate, but possibly some time in the next month. Here's what I propose: (1) update lxc-user-nic and lxc-start(?) so that: - when lxc.network.link is not specified on lxc config file, it will pass "none" as bridge name to lxc-user-nic - lxc-user-nic does not actually add the interface to any bridge when "bridge" parameter is "none", so that /etc/lxc/lxc-usernet can have entries like this # USERNAME TYPE BRIDGE COUNT user veth lxcbr0 10 user veth none 10 This one should be pretty straight forward and easiest to implement (2) Allow custom veth name on the host side. The best way I can think of is to add one more parameters to lxc-user-nic. Currently: $ /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic Usage: /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic pid type bridge nicname nicname is the name to use inside the container ... will become Usage: /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic pid type bridge nicname [pairname] nicname is the name to use inside the container. pairname is the name to use for the veth pair on the host, only valid when "type" is "veth". If pairname is empty, veth pair name will be autogenerated. We also add /etc/lxc/lxc-usernet-veth-pairname, which will be used by lxc-usernet when pairname is not empty, and has this format # USERNAME PAIRNAME(15 chars max) user veth-user-c1-0 user veth-user-c2-0 user veth-user-c2-1 user2 veth-user2-c1-0 user2 veth-user2-c2-0 As an alternative, you could also only enforce the prefix, so that the format becomes like this # USERNAME PAIRNAME_PREFIX user veth-user- user2 veth-user2- In both cases, the nic count is enforced by /etc/lxc/lxc-usernet, and /etc/lxc/lxc-usernet-veth-pairname is only used to enforce veth pair name compliance. (3) sometime in the future: add support for lxc.network.type="proxyarp" It would create veth nic, and does the configuration on the host side (enable proxyarp, setup ip including its pointopoint pair) and the container side. When using lxc.network.type="proxyarp": - lxc.network.link is used to specify which host interface will have proxyarp enabled (eth0 in my previous example) - lxc.network.ipv4 is used to specify IP on the container side (192.168.124.251 in my previous example) - lxc.network.ipv4.gateway is used to specify pointopoint IP on the host side (which is also used as gateway inside the container). On my example I used 172.16.0.1. We could probably assign "169.254.1.1" (a link-local address) as the default IP to use when this config item is not set. Are you ok with that design? -- Fajar _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users