a work for lxc monitor network interface

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.

Quoted 27 lines · Libo Chen

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

Quoted 4 lines

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.

.

Quoted 28 lines · Serge Hallyn

Quoted 27 lines · Libo Chen

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

Quoted 9 lines

Quoted 4 lines

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?

Quoted 43 lines · Libo Chen

Quoted 28 lines · Serge Hallyn

Quoted 27 lines · Libo Chen

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

Quoted 9 lines

Quoted 4 lines

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.

Quoted 1 line

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)

.

Quoted 44 lines · Serge Hallyn

Quoted 43 lines · Libo Chen

Quoted 28 lines · Serge Hallyn

Quoted 27 lines · Libo Chen

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

Quoted 9 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 1 line

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

Quoted 78 lines · Libo Chen

Quoted 44 lines · Serge Hallyn

Quoted 43 lines · Libo Chen

Quoted 28 lines · Serge Hallyn

Quoted 27 lines · Libo Chen

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

Quoted 9 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 1 line

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:

Quoted 7 lines

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?

-serge

.