On 2014/1/22 22:17, Serge Hallyn wrote: > Quoting Libo Chen (clbchenlibo.chen@xxxxxxxxxx): >> 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 > > Since most hosts already have a well-understood daemon watching uevents, > udev/mdev/probably others, I still think it would be better for users > who want this behavior to write a udev rule which fires off > lxc-device. > > In your design, would there be one long-running daemon for all > containers, which each container registers nics with, or a > daemon per container? a daemon per container, so container can track the uevents it is interested and this makes code simple. Libo > > -serge > > . > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
