Networking Issue

LXD
1

Ok…I have a Windows 7 PC with a Virtual Box VM Ubuntu 16.04.4 installed and updated.
I then created a LXD container on the Ubuntu VM. Here are the IP’s:

  1. Windows 7: 192.168.1.149
  2. Ubuntu VM: 192.168.1.141
  3. Container: 10.160.70.131

And here are the ping results between the 3 machines:
3 can ping 1 & 2 successfully.
2 can ping 1 & 3 successfully
1 can ping 2 successfully
1 cannot ping 3

Also note that 3 can ping yahoo.com successfully.

Any ideas why the Windows box cannot ping the Container? (This seems trivial but I’m no networking expert…not even a little.)

Thanks and appreciate your responses.

Ray

2

Both the 192.168.*.* and the 10.*.*.* networks are private not-routable networks. It is a standard networking issue and you cannot route from one of those private networks to get to somewhere else. When your packets get into one such private network, they end there and cannot get routed further away (to the other private network).

So, what do you do? If you want to expose some of the containers to the Windows 7 machine (just like the Ubuntu VM is), then you can put (some of) the container on either a bridge or a macvlan.

See The LXD tutorials of Simos and search for bridge and macvlan on how to do that. In both cases, the containers (you can select which) will be a 192.168.1.x IP address, just like the Ubuntu VM.
Note that for macvlan, the containers will not be able to communicate with the host (Ubuntu VM).

3

Thanks. I tried to follow the example at https://blog.simos.info/how-to-make-your-lxd-containers-get-ip-addresses-from-your-lan-using-a-bridge/ but right off the bat the “lxc create profile bridgeprofile” command fails. There is no create option?

Also the “lxc profile list” command results in “default docker” ? I didn’t think I was actually using docker. I thought LXD was separate from Docker?

Ray

4

What exact error do you get with lxc create profile bridgeprofile?

ubuntu@nested:~$ lxc --version
2.0.11
ubuntu@nested:~$ lxc profile create bridgeprofile
Profile bridgeprofile created
ubuntu@nested:~$

LXD comes with two profiles, default and docker. The default is default. You would use the docker profile when you create LXD containers that will use Docker inside them (not relevant here).

5

ray@LPContainers:~$ lxc create profile bridgeprofile
Usage: lxc [options]

This is the LXD command line client.

All of LXD’s features can be driven through the various commands below.
For help with any of those, simply call them with --help.

Commands:
config Change container or server configuration options
copy Copy containers within or in between LXD instances
delete Delete containers and snapshots
exec Execute commands in containers
file Manage files in containers
image Manipulate container images
info Show container or server information
launch Create and start containers from images
list List the existing containers
move Move containers within or in between LXD instances
profile Manage container configuration profiles
publish Publish containers as images
remote Manage the list of remote LXD servers
restart Restart containers
restore Restore containers from snapshots
snapshot Create container snapshots
start Start containers
stop Stop containers
version Print the version number of this client tool

Options:
–all Print less common commands
–debug Print debug information
–verbose Print verbose information
–version Show client version

Environment:
LXD_CONF Path to an alternate client configuration directory
LXD_DIR Path to an alternate server directory

error: unknown command: create

ray@LPContainers:~$ lxc --version
2.0.11

6

The command is lxc, and the subcommand is profile.
Therefore, you need to type in this order, lxc profile in order to invoke actions relating to profile (such as create to create a new profile).

Therefore, try again with lxc profile create bridgeprofile.

LXD 2.0.11 is somewhat old but properly supported until 2021. If you notice though that a command/subcommand/action is not working, do mention it because I did not check my tutorial with LXD 2.0.11 (but with a more recent LXD).

7

So I created the bridgeprofile:

root@LP:/livepeer_linux.0.1.14.tar/livepeer_linux# lxc profile list
default
docker
bridgeprofile

but this command is not working: $ lxc profile assign LP default,bridgeprofile
error: wrong number of subcommand arguments

Ray

8

I am reading that LXD 2.0.11 has instead lxc profile apply (and not lxc profile assign).

Therefore, try instead

lxc profile apply LP default,bridgeprofile

9

I wasn’t having a lot of luck with bridgeprofile so I am trying your macvlan tutorial.

So on my lxc host:
ray@LPContainers:~$ ip route show default 0.0.0.0/0
default via 192.168.1.1 dev enp0s3

I ran the following 2 commands:
lxc profile device set lanprofile eth0 nictype macvlan

lxc profile device set lanprofile eth0 parent enp0s3

lxc profile show lanprofile

config: {}
description: Default LXD profile
devices:
eth0:
name: eth0
nictype: macvlan
parent: enp0s3
type: nic
name: lanprofile
used_by: []

I launched LP2 and here is it’s ipconfig:
root@LP2:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3e:8d:42:eb
inet6 addr: fe80::216:3eff:fe8d:42eb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:67 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:5122 (5.1 KB) TX bytes:6804 (6.8 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

And pinging my LAN Windows box:
root@LP2:~# ping 192.168.1.149
connect: Network is unreachable

Here is my Windows ipconfig:
Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : tampabay.rr.com
IPv4 Address. . . . . . . . . . . : 192.168.1.149
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Tunnel adapter isatap.tampabay.rr.com:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : tampabay.rr.com

Ideas?

Ray

10

When you initialized LXD with lxd init, probably a LXD bridge lxdbr0 was created. The default profile uses this network and your container receives the IP 10.160.70.131 via dhcp (there is dhcp server in the lxdbr0 network). You can see information about the profile and network with:
$ lxc profile show default
$ lxc network show lxdbr0

If your container is using that profile and the lxdbr0 network:

  • The container can communicate with the Ubuntu VM and Internet (he starts the communication)
  • The Ubuntu VM can communicate with your container (the Ubuntu VM starts the communication), thanks both they are connect to the network lxdbr0.
  • Windows (or from hosts in the lan) can not communicate with your container because it’s in an ‘isolate’ network (lxdbr0). You have to create DNAT rules in the Ubuntu VM in order to allow access from the outside to services running in the container.

If you configure a new profile in order to work in bridge mode, you have to configure the network adapter in Virtualhost as bridge mode and Promiscuous mode - Allow all.

Mode macvlan did not work for me in Virtualbox (I tried it a few months ago).

I suppose that you are not working with wifi. If you are working with wifi, neither the bridge nor the macvlan, will work.

Salutes

12

Hiya
I think the default setup for the lxd bridge is that it will NAT to the IP of the ubuntu host when you ping anything on the physical network (in this case windows pc)

To ping the container inside you can either route to the container, using your ubuntu vm as the next hop for the 10.x container network (in the context of outside devices sending)

Or as above use macvlan where you ditch the internal bridge and the containers will get an IP on the physical network. The downsides are you will never be able to ping the ubuntu host from the container using macvlan, only the physical network.