I first brought this issue up several weeks ago and have just got back
to the work where I originally ran into this problem. The scenario is
simple enough:
- Create two EC2 instances running CentOS 7.1
- Configure these instances to used bridged networking
- Create a LXC container running under each instance, using the command
lxc-create -t download -n test1 --dir=/hf/test1/rootfs -- -d centos
-r 7 -a amd64
Each container ends up with a config that looks something like this:
lxc.include = /usr/share/lxc/config/centos.common.conf
lxc.arch = x86_64
lxc.rootfs = /hf/test1/rootfs
lxc.utsname = test1
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:xx:xx:xx
- Assign each EC2 instance and container a static IP address in the same
subnet. In my test I assigned the two EC2 instances 10.0.0.102 and
10.0.0.108 and the two containers 10.0.0.103 and 10.0.0.109.
In this scenario, each EC2 host can ping their own LXC container, and
they can ping each other. Likewise, the containers can ping their host.
However, Instance 102 cannot ping the container hosted on instance 108,
and similarly instance 108 cannot ping the container hosted on instance
102. If I configure this exact same scenario on real hardware or on KVM
based virtual machines, this "crosstalk" problem does not
occur--instance 102 can ping container 109 for example, even though it
is hosted on a difference instance.
From what I've read, I understand that Amazon has implemented some
special/restricted behavior for the networking stack of EC2 instances.
The question I have is whether I can accomplish what I've attempted
here, specifically, can I access a LXC container hosted on one EC2
instance directly from another EC2 instance or from another LXC
container hosted on another EC2 instance?
Peter
_______________________________________________
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
