On 2014/1/7 0:55, Serge Hallyn wrote: > Quoting Libo Chen (clbchenlibo.chen@xxxxxxxxxx): >> On 2013/12/19 4:16, Serge Hallyn wrote: >>> Quoting Libo Chen (clbchenlibo.chen@xxxxxxxxxx): >>>> Hello LXC experts, >>>> >>>> lxc tool can set network interface by config, but it is static. >>>> In some scene, the network interface will be dynamic created on the host >>>> and need be shared to container, but it is not suitable to do by hand, >>>> so lxc can not work for it. >>>> >>>> I also know lxc_user_nic() can only do a part of work, but we have >>>> two more work: >>>> 1. grasp the netlink/uevent message about network interface online >>>> 2. config interface attached to container ip address . >>>> >>>> so it can not fully meet my requirements. >>>> >>>> I want there is a monitor can work for network interface hotplug. >>>> >>>> 1. read config form config file, it describe monitor which network interface >>>> and what's the network configuration >>>> 2. grasp the netlink/uevent message about network interface online on the host >>>> 3. create veth pair, put veth attach to container and bridge >>>> 4. config the veth attached to container ipaddr >>>> >>>> >>>> netlink create veth pair >>>> monitor ---> read config -------> veth0 attach to container --> config ipaddr >>>> veth1 attach to bridge >>>> >>>> monitor may be the lxc-start or a child forked by lxc-start. >>>> >>>> >>>> Is this reasonable? If so, I'd like to do it. >>> >>> I'm not quite clear on what you're trying to do, but it sounds like you >>> could use a udev rule, triggered on the nic creation, and use lxc-device >>> from inside that rule to attach the nic to the container. >>> >> hi Serge, >> >> using udev rule is a good idea, but not common. for instance android uses ueventd and >> busybox uses mdev, sometimes nothing at all. >> >> so how about lxc itself provides this feature? > > Just one more question - what would the configuration look like? > Especially, what would the monitor be looking for? How would it > recognzie a link that came up as being the one which the container > should be attached to? (We're constantly reminded that the names > cannot be unambiguously used to identify a physical link) > My idea is this, may not reason. 1. I would like to add a field 'lxc.network.dynamic' which describes a static or dynamic nic in config file. if lxc.network.dynamic = false(default false), lxc should go as before,else it means the following device will appear in a future time. e.g. lxc.network.dynamic = true lxc.network.type = veth // need veth mode to container lxc.network.flags = up lxc.network.link = br0 // be attached to lxc.network.name = ppp0 //monitor nic ppp0 e.g. lxc.network.dynamic = true lxc.network.type = phys // direct to container lxc.network.flags = up lxc.network.name = ppp0 //monitor nic ppp0 2.the monitor should look for uevent, since uevent message includes interface name like: add@/devices/virtual/net/veth5 ACTION=add DEVPATH=/devices/virtual/net/veth5 SUBSYSTEM=net INTERFACE=veth5 **** IFINDEX=19 SEQNUM=12292 > . > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
