I’m using the package 2.0.7-2~bpo8+1 on Debian Jessie. (from backports)
According to the topic here - I should use man pages to get the current documentation.
If I follow man lxc.info - I should use the network key with the index [i]:
lxc-info -n foo -c lxc.network.0.veth.pair
it I try it with the following cmd, it works like documented:
lxc-info -n test -c lxc.network.0.ipv4
lxc.network.0.ipv4 =
if I use the config key which is documented for lcx.container.conf, it’s not working:
lxc.network.ipv4
specify the ipv4 address to assign to the virtualized interface. Several lines specify several ipv4 addresses. The address is in format x.y.z.t/m, eg. 192.168.1.123/24. The broadcast address should be specified on the same line, right after the ipv4 address.
lxc-info -n test -c lxc.network.ipv4
lxc.network.ipv4 invalid
It looks like, some parts already using the API / config for LXC 2.1 and some not.
I’m working on a Puppet LXC container management module, using the ruby-lxc 1.2.2 bindings and it has no constant behavior, which makes it very complicated to implement the provider.
You picked what’s probably the worst example of config key handling, network…
The lxc.network.* keys have always been a bit of a mess because they can either be specified with the index, in which case the parser attempts to guess what belongs to what device based on the order AND we support (and internally use) the indexed syntax.
So in current stable LXC, both of those are considered identical:
lxc.network.type = veth
lxc.network.link = lxdbr0
lxc.network.flags = up
lxc.network.type = veth
lxc.network.link = lxdbr1
lxc.network.flags = up
lxc.network.0.type = veth
lxc.network.0.link = lxdbr0
lxc.network.0.flags = up
lxc.network.1.type = veth
lxc.network.1.link = lxdbr0
lxc.network.1.flags = up
The problem you’re running into is that while we do allow for both ways of specifying the configuration (for backward compatibility), we don’t allow querying the internal state with the old order-dependent syntax.
With LXC 2.1 and higher, this will be fixed with the transition to using “lxc.net” rather than “lxc.network”. “lxc.net” only supports indexed keys and “lxc.network” will be dropped entirely with LXC 3.0, finally cleaning up this mess.