이것은 사용자가 2025-1-6 15:12에 https://blog.simos.info/how-to-make-your-lxd-container-get-ip-addresses-from-your-lan/comment-page-1...을(를) 위해 저장한 이중 언어 스냅샷 페이지로, 몰입형 번역에 의해 제공된 이중 언어 지원이 있습니다. 저장하는 방법을 알아보세요?

How to make your LXD containers get IP addresses from your LAN using macvlan
LXD 컨테이너가 macvlan을 사용하여 LAN에서 IP 주소를 받도록 만드는 방법

Update 22 June 2020 I have updated this post to be compatible with LXD 4.0. I also adapted it in order to create an empty profile that does only the macvlan stuff and is independent of the default profile. Finally, I am calling the profile macvlan (previous name: lanprofile).
2020년 6월 22일 업데이트 이 게시물을 LXD 4.0과 호환되도록 업데이트했습니다. 또한 기본 프로필과 독립적이며 macvlan 작업만 수행하는 빈 프로필을 만들기 위해 조정했습니다. 마지막으로 이 프로필을 macvlan 라고 부릅니다(이전 이름: lanprofile).

WARNING #1: By using macvlan, your computer’s network interface will appear on the network to have more than one MAC address. This is fine for Ethernet networks. However, if your interface is a Wireless interface (with security like WPA/WPA2), then the access point will reject any other MAC addresses coming from your computer. Therefore, all these will not work in that specific case.
경고 #1: macvlan을 사용하면 컴퓨터의 네트워크 인터페이스가 네트워크에서 여러 개의 MAC 주소를 가진 것처럼 나타납니다. 이는 이더넷 네트워크에서는 괜찮습니다. 그러나 인터페이스가 무선 인터페이스(WPA/WPA2와 같은 보안이 있는 경우)인 경우, 액세스 포인트는 컴퓨터에서 오는 다른 MAC 주소를 거부합니다. 따라서 이러한 모든 것은 해당 특정 경우에 작동하지 않습니다.

WARNING #2: If your host is in a virtual machine, then it is likely that the VM software will block the DHCP requests of the containers. There are options on both VMWare and Virtualbox to allow Promiscuous mode (somewhere in their Network settings). You need to enable that. Keep in mind that people reported success only on VMWare. Currently, on VirtualBox, you need to switch the network interface on the host into the PROMISC mode, as a workaround.
경고 #2: 호스트가 가상 머신에 있는 경우, VM 소프트웨어가 컨테이너의 DHCP 요청을 차단할 가능성이 높습니다. VMWare와 Virtualbox 모두에서 Promiscuous 모드를 허용하는 옵션이 있습니다(네트워크 설정의 어딘가에 있습니다). 이를 활성화해야 합니다. 사람들이 VMWare에서만 성공했다고 보고했다는 점을 염두에 두십시오. 현재 VirtualBox에서는 호스트의 네트워크 인터페이스를 PROMISC 모드로 전환해야 합니다.

In LXD terminology, you have the host and then you have the many containers on this host. The host is the computer where LXD is running. By default, all containers run hidden in a private network on the host. The containers are not accessible from the local network, nor from the Internet. However, they have network access to the Internet through the host. This is NAT networking.
LXD 용어에서 호스트가 있고, 그 호스트에 여러 개의 컨테이너가 있습니다. 호스트는 LXD가 실행되고 있는 컴퓨터입니다. 기본적으로 모든 컨테이너는 호스트의 개인 네트워크에서 숨겨져 실행됩니다. 컨테이너는 로컬 네트워크나 인터넷에서 접근할 수 없습니다. 그러나 호스트를 통해 인터넷에 대한 네트워크 접근이 가능합니다. 이것이 NAT 네트워킹입니다.

How can we get some containers to receive an IP address from the LAN and be accessible on the LAN?
LAN에서 IP 주소를 수신하고 LAN에서 접근 가능하도록 컨테이너를 어떻게 설정할 수 있나요?

This can be achieved using macvlan (L2) virtual network interfaces, a feature provided by the Linux kernel.
이것은 리눅스 커널에서 제공하는 기능인 macvlan (L2) 가상 네트워크 인터페이스를 사용하여 달성할 수 있습니다.

In this post, we are going to create a new LXD profile and configure macvlan in it. Then, we launch new containers under the new profile, or attach existing containers to the new profile (so they get as well a LAN IP address).
이 게시물에서는 새로운 LXD 프로필을 생성하고 그 안에 macvlan을 구성할 것입니다. 그런 다음, 새로운 프로필 아래에 새로운 컨테이너를 시작하거나 기존 컨테이너를 새로운 프로필에 연결하여 LAN IP 주소를 받도록 합니다.

Creating a new LXD profile for macvlan
macvlan을 위한 새로운 LXD 프로필 생성

Let’s see what LXD profiles are available.
LXD 프로필이 어떤 것이 있는지 봅시다.

$ lxc profile list
+------------+---------+
| NAME       | USED BY |
+------------+---------+
| default    | 11      |
+------------+---------+

There is a single profile, called default, the default profile. It is used by 11 LXD containers on this system.
기본이라고 불리는 단일 프로필이 있습니다. 이 프로필은 이 시스템의 11개의 LXD 컨테이너에서 사용됩니다.

We create a new profile. The new profile is called macvlan.
새 프로필을 생성합니다. 새 프로필의 이름은 macvlan입니다.

$ lxc profile create macvlan
Profile macvlan created
$ lxc profile list
+------------+---------+
| NAME       | USED BY |
+------------+---------+
| default    | 11      |
+------------+---------+
| macvlan    | 0       |
+------------+---------+

What are the default settings of a new profile?
새 프로필의 기본 설정은 무엇인가요?

$ lxc profile show macvlan
config: {}
description: ""
devices: {}
name: macvlan
used_by: []
$ 

We need to add a nic with nictype macvlan and parent to the appropriate network interface on the host and we are then ready to go. Let’s identify the correct parent, using the ip route command. This command shows the default network route. It also shows the name of the device (dev), which is in this case enp5s12. (Before systemd, those used to be eth0 or wlan0. Now, the name varies depending on the specific network cards).
우리는 호스트의 적절한 네트워크 인터페이스에 nictype macvlan 와 부모를 가진 nic를 추가해야 하며, 그러면 준비가 완료됩니다. ip route 명령을 사용하여 올바른 부모를 식별해 봅시다. 이 명령은 기본 네트워크 경로를 보여줍니다. 또한 이 경우 장치(dev)의 이름인 enp5s12를 보여줍니다. (systemd 이전에는 eth0 또는 wlan0이 사용되었습니다. 이제 이름은 특정 네트워크 카드에 따라 다릅니다).

$ ip route show default 0.0.0.0/0
default via 192.168.1.1 dev enp5s12 proto static metric 100

Now we are ready to add the appropriate device to the macvlan LXD profile. We use the lxc profile device add command to add a device eth0 to the profile lanprofile. We set nictype to macvlan, and parent to enp5s12.
이제 macvlan LXD 프로필에 적절한 장치를 추가할 준비가 되었습니다. lxc profile device add 명령을 사용하여 lanprofile 프로필에 eth0 장치를 추가합니다. nictype을 macvlan으로 설정하고, parent를 enp5s12로 설정합니다.

$ lxc profile device add macvlan eth0 nic nictype=macvlan parent=enp5s12
Device eth0 added to macvlan
$ lxc profile show macvlan
config: {}
description: ""
devices:
  eth0:
    nictype: macvlan
    parent: enp5s12
    type: nic
name: macvlan
used_by: []
ubuntu@myvm:~$ 
$ 

Well, that’s it. We are now ready to launch containers using this new profile, and they will get an IP address from the DHCP server of the LAN.
그게 다입니다. 이제 이 새로운 프로필을 사용하여 컨테이너를 시작할 준비가 되었으며, 이들은 LAN의 DHCP 서버에서 IP 주소를 받을 것입니다.

Launching LXD containers with the new profile
새 프로필로 LXD 컨테이너 시작하기

Let’s launch two containers using the new macvlan profile and then check their IP address. We need to specify first the default profile, and then the macvlan profile. By doing this, the container will get the appropriate base configuration from the first profile, and then the networking will be overridden by the macvlan profile.
새로운 macvlan 프로필을 사용하여 두 개의 컨테이너를 실행한 다음 IP 주소를 확인해 보겠습니다. 먼저 default 프로필을 지정한 다음 macvlan 프로필을 지정해야 합니다. 이렇게 하면 컨테이너는 첫 번째 프로필에서 적절한 기본 구성을 가져오고, 그 다음 macvlan 프로필에 의해 네트워킹이 재정의됩니다.

$ lxc launch ubuntu:18.04 net1 --profile default --profile macvlan
Creating net1
Starting net1
$ lxc launch ubuntu:18.04 net2 --profile default --profile macvlan
Creating net2
Starting net2
$ lxc list
+------+---------+---------------------+------+-----------+-----------+
| NAME |  STATE  |        IPV4         | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+---------------------+------+-----------+-----------+
| net1 | RUNNING | 192.168.1.7 (eth0)  |      | CONTAINER | 0         |
+------+---------+---------------------+------+-----------+-----------+
| net2 | RUNNING | 192.168.1.3 (eth0)  |      | CONTAINER | 0         |
+------+---------+---------------------+------+-----------+-----------+
$ 

Both containers got their IP address from the LAN router. Here is the router administration screen that shows the two containers. I edited the names by adding LXD in the front to make them look nicer. The containers look and feel as just like new LAN computers!
두 컨테이너는 LAN 라우터에서 IP 주소를 받았습니다. 여기 두 컨테이너를 보여주는 라우터 관리 화면이 있습니다. 이름을 더 보기 좋게 만들기 위해 앞에 LXD를 추가하여 편집했습니다. 컨테이너는 마치 새로운 LAN 컴퓨터처럼 보이고 느껴집니다!

Let’s ping from one container to the other.
한 컨테이너에서 다른 컨테이너로 핑을 보내봅시다.

$ lxc exec net1 -- ping -c 3 192.168.1.7
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
64 bytes from 192.168.1.7: icmp_seq=1 ttl=64 time=0.064 ms
64 bytes from 192.168.1.7: icmp_seq=2 ttl=64 time=0.067 ms
64 bytes from 192.168.1.7: icmp_seq=3 ttl=64 time=0.082 ms

--- 192.168.1.7 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms
rtt min/avg/max/mdev = 0.064/0.071/0.082/0.007 ms

You can ping these containers from other computers on your LAN! But the host and these macvlan containers cannot communicate over the network. This has to do with how macvlan works in the Linux kernel.
이 컨테이너들은 LAN의 다른 컴퓨터에서 핑을 받을 수 있습니다! 그러나 호스트와 이 macvlan 컨테이너들은 네트워크를 통해 통신할 수 없습니다. 이는 macvlan이 리눅스 커널에서 작동하는 방식과 관련이 있습니다.

Troubleshooting  문제 해결

Help! I cannot ping between the host and the containers!
도와주세요! 호스트와 컨테이너 간에 핑을 보낼 수 없습니다!

To be able to get the host and containers to communicate with each other, you need some additional changes to the host in order to get added to the macvlan as well. It discusses it here, though I did not test because I do not need communication of the containers with the host. If you test it, please report below.
호스트와 컨테이너가 서로 통신할 수 있도록 하려면, macvlan에 추가되기 위해 호스트에 몇 가지 추가 변경이 필요합니다. 여기에서 논의하지만, 저는 호스트와의 컨테이너 통신이 필요하지 않기 때문에 테스트하지 않았습니다. 테스트하신다면 아래에 보고해 주세요.

Help! I do not get anymore those net1.lxd, net2.lxd fancy hostnames!
도와주세요! 더 이상 net1.lxd, net2.lxd 멋진 호스트 이름을 받지 못하고 있습니다!

The default LXD DHCP server assigns hostnames like net1.lxd, net2.lxd to each container. Then, you can get the containers to communicate with each other using the hostnames instead of the IP addresses.
기본 LXD DHCP 서버는 각 컨테이너에 net1.lxd, net2.lxd와 같은 호스트 이름을 할당합니다. 그런 다음 IP 주소 대신 호스트 이름을 사용하여 컨테이너 간에 통신할 수 있습니다.

When using the LAN DHCP server, you would need to configure it as well to produce nice hostnames.
LAN DHCP 서버를 사용할 때, 멋진 호스트 이름을 생성하도록 구성해야 합니다.

Help! Can these new macvlan containers read my LAN network traffic?
도와주세요! 이 새로운 macvlan 컨테이너들이 내 LAN 네트워크 트래픽을 읽을 수 있나요?

The new macvlan LXD containers (that got a LAN IP address) can only see their own traffic and also any LAN broadcast packets. They cannot see the traffic meant for the host, nor the traffic for the other containers.
새로운 macvlan LXD 컨테이너(랜 IP 주소를 받은)는 자신의 트래픽과 LAN 브로드캐스트 패킷만 볼 수 있습니다. 호스트를 위한 트래픽이나 다른 컨테이너를 위한 트래픽은 볼 수 없습니다.

Help! I get the error Error: Device validation failed “eth0”: Cannot use “nictype” property in conjunction with “network” property
도와주세요! Error: Device validation failed “eth0”: Cannot use “nictype” property in conjunction with “network” property 오류가 발생합니다

A previous version of this tutorial had the old style of how to add a device to a LXD profile. The old style was supposed to work in compatibility mode in newer versions of LXD. But at least in LXD 4.2 it does not, and gives the following error. You should not get this error anymore since I have updated the post. You may get an error if you are using a very old LXD. In that case, report back in the comments please.
이 튜토리얼의 이전 버전은 LXD 프로필에 장치를 추가하는 구식 방법을 가지고 있었습니다. 구식 방법은 최신 버전의 LXD에서 호환성 모드로 작동해야 했습니다. 그러나 LXD 4.2에서는 작동하지 않으며 다음과 같은 오류가 발생합니다. 제가 게시물을 업데이트했기 때문에 더 이상 이 오류가 발생하지 않아야 합니다. 매우 오래된 LXD를 사용하고 있다면 오류가 발생할 수 있습니다. 그런 경우에는 댓글로 알려주세요.

$ lxc profile device set macvlan eth0 nictype macvlan
Error: Device validation failed "eth0": Cannot use "nictype" property in conjunction with "network" property
$

Summary  요약

With this tutorial, you are able to create containers that get an IP address from the LAN (same source as the host), using macvlan.
이 튜토리얼을 통해 macvlan을 사용하여 LAN(호스트와 동일한 출처)에서 IP 주소를 얻는 컨테이너를 생성할 수 있습니다.

A downside is that the host and these macvlan containers cannot communicate over the network. For some, this is a neat advantage, because they shield the host from the containers.
단점은 호스트와 이러한 macvlan 컨테이너가 네트워크를 통해 통신할 수 없다는 것입니다. 일부에게는 이것이 호스트를 컨테이너로부터 보호하기 때문에 멋진 장점입니다.

The macvlan containers are then visible on the LAN and work just like another LAN computer.
macvlan 컨테이너는 LAN에서 보이며 다른 LAN 컴퓨터처럼 작동합니다.

This tutorial has been updated with the newer commands to edit a LXD profile (lxc profile device add). The older command now gives an error as you can see in the more recent comments below.
이 튜토리얼은 LXD 프로필을 편집하는 새로운 명령어로 업데이트되었습니다 ( lxc profile device add ). 이전 명령어는 아래의 최근 댓글에서 볼 수 있듯이 이제 오류를 발생시킵니다.

Permanent link to this article: https://blog.simos.info/how-to-make-your-lxd-container-get-ip-addresses-from-your-lan/

86 comments
86 댓글

10 pings
10 핑

Skip to comment form
댓글 양식으로 건너뛰기

  1. Great write-up Simos…  훌륭한 글이야 시모스…

  2. Great – thanks for the brilliant written article – it works now!
    좋습니다 – 훌륭한 글을 써 주셔서 감사합니다 – 이제 잘 작동합니다!

  3. I did it with the above post, but the container vm can not get the ip address. Tell me how to fix the problem.
    위의 게시물로 했지만, 컨테이너 VM이 IP 주소를 받을 수 없습니다. 문제를 해결하는 방법을 알려주세요.

    The test environment is DHCP.
    테스트 환경은 DHCP입니다.

    [root@ns01 ~]# uname -a
    Linux ns01 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux (centos 7)

    [root@ns01 ~]# lxc list  [root@ns01 ~]# lxc 목록
    +——+———+——+——+————+———–+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
    +——+———+——+——+————+———–+
    | c2 | RUNNING | | | PERSISTENT | 0 |
    | c2 | 실행 중 | | | 지속적 | 0 |

    +——+———+——+——+————+———–+

    [root@ns01 ~]# lxc profile show lanprofile
    config: {}
    description: Default LXD profile
    기본 LXD 프로필

    devices:  장치:
    eth0:
    name: eth0
    nictype: macvlan
    parent: ens160
    type: nic
    root:
    path: /
    pool: default
    type: disk  타입: 디스크
    name: lanprofile
    used_by:
    – /1.0/containers/c2

    [root@ns01 ~]# ifconfig ens160
    ens160: flags=4163 mtu 1500
    inet 192.168.50.30 netmask 255.255.255.0 broadcast 192.168.50.255
    inet6 fe80::9e56:786c:39be:e30a prefixlen 64 scopeid 0x20
    ether 00:0c:29:22:66:3e txqueuelen 1000 (Ethernet)
    RX packets 4342 bytes 1841714 (1.7 MiB)
    RX 패킷 4342 바이트 1841714 (1.7 MiB)

    RX errors 0 dropped 12 overruns 0 frame 0
    RX 오류 0 드롭 12 오버런 0 프레임 0

    TX packets 2515 bytes 262656 (256.5 KiB)
    TX 패킷 2515 바이트 262656 (256.5 KiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    TX 오류 0 드롭 0 오버런 0 캐리어 0 충돌 0

    [root@ns01 ~]# ip route show 0.0.0.0/0
    default via 192.168.50.1 dev ens160 proto static metric 100

    ======= below c2 (centos 7) ======
    [root@c2 ~]# ip -d link show eth0
    7: eth0@if2: mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1000
    link/ether 00:16:3e:f4:6f:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0
    macvlan mode bridge addrgenmode eui64
    macvlan 모드 브리지 addrgenmode eui64

    Thanks.  감사합니다.

    1. Do you use a VM for the host? If so, then the VM might be the issue.
      호스트에 VM을 사용하나요? 그렇다면 VM이 문제일 수 있습니다.

      Also, if the host is on a wireless interface, then that’s definitely the issue.
      또한, 호스트가 무선 인터페이스에 있다면, 그것이 확실히 문제입니다.

  4. I am getting this error when I try to start a macvlan container :
    macvlan 컨테이너를 시작하려고 할 때 이 오류가 발생합니다:

    ray@USN-LPC:/var/lib/lxd/containers$ lxc start LPC2
    error: Failed to run: /usr/bin/lxd forkstart LPC2 /var/lib/lxd/containers /var/log/lxd/LPC2/lxc.conf:
    Try `lxc info –show-log LPC2` for more info

    ray@USN-LPC:/var/lib/lxd/containers$ lxc info LPC2
    Name: LPC2
    Remote: unix://
    Architecture: x86_64
    Created: 2018/05/26 13:14 UTC
    Status: Stopped  상태: 중지됨
    Type: persistent  유형: 지속적
    Profiles: lanprofile

    ray@USN-LPC:/var/lib/lxd/containers$ lxc profile show lanprofile
    config:
    environment.http_proxy: “”
    user.network_mode: “”
    description: Default LXD profile
    기본 LXD 프로필

    devices:  장치:
    eth0:
    nictype: macvlan
    parent: enp0s3
    type: nic
    root:
    path: /
    pool: lxdpool
    type: disk  타입: 디스크
    name: lanprofile
    used_by:
    – /1.0/containers/LPC2

    Ideas?  아이디어?

    Thanks.  감사합니다.

    Ray  레이

    1. What does *lxc info –show-log LPC2* show? It should give a hint of the exact error.
      *lxc info –show-log LPC2*는 무엇을 보여줍니까? 정확한 오류에 대한 힌트를 제공해야 합니다.

  5. This worked perfectly on a CentOS 7.5 1804 (core) host on 8/21/2018. I created an LXD ZFS-backed container for Ubuntu 18.04 exactly as you describe, and it automatically got an address assigned on my home network LAN by the DHCP server on that LAN. The private network on the host that LXD gave me was useless, but the methods you illustrate here are very useful. Thanks for your work, and for the clarity of exposition as well! Bravo!
    이것은 2018년 8월 21일에 CentOS 7.5 1804 (core) 호스트에서 완벽하게 작동했습니다. 저는 당신이 설명한 대로 Ubuntu 18.04를 위해 LXD ZFS 기반 컨테이너를 만들었고, 그것은 자동으로 해당 LAN의 DHCP 서버에 의해 제 홈 네트워크 LAN에서 주소가 할당되었습니다. LXD가 저에게 제공한 호스트의 개인 네트워크는 쓸모가 없었지만, 여기서 설명하는 방법들은 매우 유용합니다. 당신의 작업과 명확한 설명에 감사드립니다! 브라보!

    1. Thanks Robert for the kind words!
      친절한 말씀 감사합니다, 로버트!

    • Wouter on September 11, 2018 at 18:34
      Wouter 2018년 9월 11일 18:34
    • Reply  답장

    Thanks for your article. I did not succeed with macvlan. On Ubuntu 17.10 server I have a container running with the name proxy:
    귀하의 기사에 감사드립니다. macvlan으로 성공하지 못했습니다. Ubuntu 17.10 서버에서 proxy라는 이름의 컨테이너가 실행되고 있습니다.

    root@box:~# lxc list
    +——-+———+——+——+————+———–+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
    +——-+———+——+——+————+———–+
    | proxy | RUNNING | | | PERSISTENT | 0 |
    | 프록시 | 실행 중 | | | 지속적 | 0 |

    with this MAC:  이 MAC로:

    root@box:~# lxc exec proxy ifconfig |grep ether
    ether 00:16:3e:23:71:a9 txqueuelen 1000 (Ethernet)

    that should be getting an IP; at least, the container is asking for one and is offered one:
    그것은 IP를 받아야 합니다. 적어도 컨테이너가 하나를 요청하고 하나가 제공되고 있습니다

    Sep 11 12:06:51 box dhcpd[5314]: DHCPDISCOVER from 00:16:3e:23:71:a9 via enp1s0f1
    Sep 11 12:06:51 box dhcpd[5314]: DHCPOFFER on 192.168.12.25 to 00:16:3e:23:71:a9 via enp1s0f1

    but is not:  하지만 아니다:

    root@box:/var/log# lxc exec proxy ip a |grep inet\ 192
    root@box:/var/log# lxc exec proxy ifconfig |grep 192

    and ICMP doesnt work:
    root@box:/var/log# ping 192.168.12.25 -c1
    PING 192.168.12.25 (192.168.12.25) 56(84) bytes of data.
    PING 192.168.12.25 (192.168.12.25) 56(84) 바이트의 데이터.

    From 192.168.12.1 icmp_seq=1 Destination Host Unreachable
    From 192.168.12.1 icmp_seq=1 목적지 호스트에 도달할 수 없음

    root@box:/var/log# lxc profile show lanprofile |grep “nictype|parent”
    nictype: macvlan
    parent: enp1s0f1

    I stopped and started the container several times and also did a reinstall / reinit of lxd several times. Please help :).
    나는 여러 번 컨테이너를 중지하고 시작했으며, lxd를 여러 번 재설치/재초기화했습니다. 도와주세요 :).

    root@box:/var/log# lxc –version
    2.18

    root@box:/var/log# lxc network list |grep “lx|enp1s0f1”
    | enp1s0f1 | physical | NO | | 1 |
    | enp1s0f1 | 물리적 | 아니요 | | 1 |

    | lxcbr0 | bridge | NO | | 0 |
    | lxcbr0 | 브리지 | NO | | 0 |

    | lxdbr0 | bridge | YES | | 0 |
    | lxdbr0 | 브리지 | 예 | | 0 |

    1. Since your container requests an IP address and is offered one, then any problem should be related to the operating system of the container. I cannot think of the scenario that the DHCPOFFER being somehow blocked and not reaching the container. You can get the DHCP client in the container to output debugging information in order to see how it processes the DHCPOFFER.
      컨테이너가 IP 주소를 요청하고 제공받았으므로, 문제는 컨테이너의 운영 체제와 관련이 있어야 합니다. DHCPOFFER가 어떤 식으로든 차단되어 컨테이너에 도달하지 않는 시나리오는 생각할 수 없습니다. 컨테이너에서 DHCP 클라이언트를 사용하여 DHCPOFFER를 처리하는 방법을 확인하기 위해 디버깅 정보를 출력하도록 할 수 있습니다.

      In addition, I notice that you are running LXD 2.18. If I remember correctly, you probably use a PPA or the backports repository. I suggest to upgrade to the snap package, which currently has LXD 3.4. An upgrade should not directly fix the issue that you are facing. However, version 2.18 of LXD is not supported as far as I remember. Only version 2.0.11 (Ubuntu 16.04), 3.0.x (Ubuntu 18.04) are supported until the EOL of the corresponding LTS Ubuntu version.
      또한, 당신이 LXD 2.18을 실행하고 있다는 것을 알게 되었습니다. 제가 기억하기로는, 아마 PPA 또는 백포트 저장소를 사용하고 있을 것입니다. 현재 LXD 3.4가 있는 스냅 패키지로 업그레이드할 것을 제안합니다. 업그레이드는 당신이 직면하고 있는 문제를 직접적으로 해결하지는 않을 것입니다. 그러나 제가 기억하기로 LXD 2.18은 지원되지 않습니다. 지원되는 버전은 2.0.11 (우분투 16.04), 3.0.x (우분투 18.04)만 해당 LTS 우분투 버전의 EOL까지 지원됩니다.

        • Wouter on September 12, 2018 at 08:38
          Wouter 2018년 9월 12일 08:38
        • Reply  답장

        I was runnng 2.18 and upgraded via backports (thanks for the hint) to 2.21. No luck. Also, I launched both 16.04 and 18.04 containers with 2.21: no luck. dhclient -v eth0 says
        Listening on LPF/eth0/00:16:3e:db:e2:ce
        Sending on LPF/eth0/00:16:3e:db:e2:ce
        LPF/eth0/00:16:3e:db:e2:ce 전송 중

        Sending on Socket/fallback
        소켓/폴백으로 전송 중

        DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x548c1235)
        how… I don’t understand, but it seems the answer (DHCPOFFER) is not received. Giving up for now. First, find time to reinstall the box with Ubuntu 18.04 and then further with LXD 3.x.
        어떻게… 이해가 안 되지만, 답변(DHCPOFFER)이 수신되지 않은 것 같습니다. 지금은 포기합니다. 먼저, Ubuntu 18.04로 박스를 재설치할 시간을 찾고, 그 다음에 LXD 3.x로 진행합니다.

        thanks  감사합니다

      1. If there was virtualization in play (like VirtualBox), then this would be explained easily. There is an issue with Virtualbox and the result is exactly what you describe. That is, the container does not receive the DHCPOFFER in order to continue with the rest of the protocol. The workaround in Virtualbox would be to put the host’s interface in promiscuous mode.
        가상화가 작동 중이라면 (예: VirtualBox), 이는 쉽게 설명될 수 있습니다. VirtualBox에는 문제가 있으며 결과는 정확히 당신이 설명한 대로입니다. 즉, 컨테이너는 프로토콜의 나머지를 계속하기 위해 DHCPOFFER를 받지 않습니다. VirtualBox에서의 우회 방법은 호스트의 인터페이스를 프로미스큐어스 모드로 설정하는 것입니다.

    • Wouter on September 12, 2018 at 17:03
      Wouter 2018년 9월 12일 17:03
    • Reply  답장

    @Simos Xenitellis on September 12, 2018 at 16:24
    @Simos Xenitellis 2018년 9월 12일 16:24

    thanks for thinking with me. Its Ubuntu 17.10 on bare metal. Also, I installed the snap package with lxd 3.x (couldnt wait for finding time to install 18.04 :)) and it’s the same. Both 16.04 and 18.04 containers request DHCP, an offer is sent but not received.
    함께 생각해 주셔서 감사합니다. 그것은 베어 메탈에 설치된 Ubuntu 17.10입니다. 또한, lxd 3.x가 포함된 스냅 패키지를 설치했습니다(18.04를 설치할 시간을 찾는 것을 기다릴 수 없었습니다 :)). 둘 다 16.04와 18.04 컨테이너가 DHCP를 요청하며, 제안이 전송되지만 수신되지 않습니다.

    1. The macvlan functionality works in LXD, therefore I assume there is some issue with the network driver or network settings.
      LXD에서 macvlan 기능이 작동하므로, 네트워크 드라이버나 네트워크 설정에 문제가 있다고 가정합니다.

      I do not have the full picture. From the interface name (enp1s0f1), I assume it’s the second network interface of two? Can you verify with tshark that the DHCPOFFER is sent to the correct network interface?
      전체 상황을 알지 못합니다. 인터페이스 이름(enp1s0f1)으로 보아 두 개의 네트워크 인터페이스 중 두 번째인 것 같습니다. DHCPOFFER가 올바른 네트워크 인터페이스로 전송되었는지 tshark로 확인해 주실 수 있나요?

        • Wouter on September 13, 2018 at 08:44
          Wouter 2018년 9월 13일 08:44
        • Reply  답장

        Yes, enp1s0f1 is the second part of this NIC
        네, enp1s0f1은 이 NIC의 두 번째 부분입니다

        https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-controller-i350-datasheet.pdf
        Yes, I did tcpdump on enp1s0f1 and saw the DHCPOFFER there; it’s also the only interface where dhcpd is listening on.
        네, 저는 enp1s0f1에서 tcpdump를 했고 거기서 DHCPOFFER를 보았습니다. dhcpd가 듣고 있는 유일한 인터페이스이기도 합니다.

      1. I think that this stage you can post this issue on https://discuss.linuxcontainers.org/
        이 단계에서는 이 문제를 https://discuss.linuxcontainers.org/에 게시할 수 있다고 생각합니다.

        If it is a bug in LXD, it should be then reported on Github so that it gets fixed.
        LXD에 버그가 있다면, 수정될 수 있도록 Github에 보고해야 합니다.

  6. I can confirm that this is not working on a VirtualBox VM (ubuntu 18.04) as LXD host.

    1. side comment … if u have a proxmox hist inside a VirtualBox VM there is no problem whatsoever to get public IP’s for containers working (shared adapter, no promiscous mode). So whether anyone could break down how proxmox handles networking for LXC containers cure might be around the corner.
      사이드 코멘트 … 만약 VirtualBox VM 안에 proxmox 히스토리가 있다면, 컨테이너에 대한 공용 IP를 작동시키는 데 전혀 문제가 없습니다 (공유 어댑터, 비프롬스큐어 모드). 따라서 proxmox가 LXC 컨테이너의 네트워킹을 처리하는 방법을 누군가 설명할 수 있다면 해결책이 곧 다가올 수 있습니다.

      1. LXC containers can receive address from DHCP either you have to use
        LXC 컨테이너는 DHCP에서 주소를 받을 수 있습니다

        1. The “Adapter Type” should be set to “PCnet-FAST III” (not the default, which is an Intel PRO/1000 variant), see https://www.virtualbox.org/ticket/6519
        “어댑터 유형”은 “PCnet-FAST III”로 설정해야 합니다(기본값인 Intel PRO/1000 변형이 아님). https://www.virtualbox.org/ticket/6519를 참조하십시오.

        2. “Promiscuous Mode” should be set to “Allow All”.
        2. “Promiscuous Mode”는 “Allow All”로 설정해야 합니다.

        as mentioned here https://forums.virtualbox.org/viewtopic.php?t=59215

        or you can use Intel PRO/1000 variant but then you have to create a br0 manually in host and add host’s nic to br0 through /etc/network/interfaces or through netplan. Then assign br0 to containers and of course Promiscuous Mode” should be set to Allow All.
        또는 Intel PRO/1000 변형을 사용할 수 있지만, 그러면 호스트에서 br0를 수동으로 생성하고 /etc/network/interfaces 또는 netplan을 통해 호스트의 NIC를 br0에 추가해야 합니다. 그런 다음 br0를 컨테이너에 할당하고 물론 "Promiscuous Mode"는 Allow All로 설정해야 합니다.

    2. I have tried with Virtualbox (LXD running on Ubuntu 18.04 in a VirtualBox VM).
      나는 VirtualBox에서 시도해 보았습니다 (VirtualBox VM에서 Ubuntu 18.04에서 실행되는 LXD).

      I set up the Promiscuous setting in Virtualbox but macvlan did not work either.

      But when you set as well the host’s Ethernet interface in PROMISC mode, then it works.
      하지만 호스트의 이더넷 인터페이스를 PROMISC 모드로 설정하면 작동합니다.

      You can set it to PROMISC mode
      PROMISC 모드로 설정할 수 있습니다

      ip link set eth5 promisc on

      or  또는

      ifconfig eth5 promisc

      When you run proxmox, is the interface in PROMISC mode?
      proxmox를 실행할 때 인터페이스가 PROMISC 모드인가요?

  7. I have followed this article and another youtube video and have created a set of LXD containers all using Ubuntu 18.04. I want to expose one of the containers to the internet since it is the primary web server for this system. All of the systems are using Static IP using MacVlan and have been configured with netplan 50-cloud.
    이 기사를 따라하고 다른 유튜브 영상을 참고하여 모두 Ubuntu 18.04를 사용하는 LXD 컨테이너 세트를 만들었습니다. 이 시스템의 주요 웹 서버이기 때문에 컨테이너 중 하나를 인터넷에 노출하고 싶습니다. 모든 시스템은 MacVlan을 사용하여 정적 IP를 사용하고 있으며 netplan 50-cloud로 구성되었습니다.

    Host System – IP 192.168.86.100
    호스트 시스템 – IP 192.168.86.100

    LXC System – NextCloud Server – 192.168.86.101
    LXC 시스템 – 넥스트클라우드 서버 – 192.168.86.101

    LXC System – OnlyOffice Document Server – 192.168.86.102
    LXC 시스템 – OnlyOffice 문서 서버 – 192.168.86.102

    I can ping from my workstation to each of the systems, and from the system back to my work station, but when I try to ping from 2 or 3 to 1, it gets no response. I ping from 1 to 2 or 3, I get no response. I port forward to #2 on port 80. I try to access it from the web, I get page not found. I am sure I missed something, but have not found the magic key. Any thoughts?
    내 워크스테이션에서 각 시스템으로 핑을 보낼 수 있고, 시스템에서 내 워크스테이션으로 다시 핑을 보낼 수 있지만, 2 또는 3에서 1로 핑을 시도할 때 응답이 없습니다. 1에서 2 또는 3으로 핑을 보내면 응답이 없습니다. 포트 80에서 #2로 포트 포워딩을 했습니다. 웹에서 접근을 시도하면 페이지를 찾을 수 없습니다. 뭔가를 놓쳤다고 확신하지만, 마법의 열쇠를 찾지 못했습니다. 어떤 생각이 있으신가요?

  8. I got this method working, but have found I can’t set static ip’s on the containers – Did you experience anything similar? – Do you think it might be because the network is no longer managed/ or a bug? – It’s driving me mad
    이 방법이 작동하게 되었지만, 컨테이너에서 정적 IP를 설정할 수 없다는 것을 알게 되었습니다. 비슷한 경험이 있으신가요? 네트워크가 더 이상 관리되지 않거나 버그 때문일까요? 저를 미치게 하고 있습니다

    lxc network list  lxc 네트워크 목록
    +—————-+———-+———+————-+———+
    | NAME | TYPE | MANAGED | DESCRIPTION | USED BY |
    +—————-+———-+———+————-+———+
    | enp3s0 | physical | NO | | 0 |
    | enp3s0 | 물리적 | 아니요 | | 0 |

    +—————-+———-+———+————-+———+
    | enp3s0.102 | vlan | NO | | 2 |
    +—————-+———-+———+————-+———+

    lxc config device set disco-test-002 eth0 ipv4.address 172.16.102.33

    lxc config device get disco-test-002 eth0 ipv4.address
    172.16.102.33

    lxc list # After restart etc etc, ip returns to the dhcp leased address
    lxc list # 재시작 후 등등, IP가 DHCP 임대 주소로 돌아갑니다

    +—————-+———+———————-+——+————+———–+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
    +—————-+———+———————-+——+————+———–+
    | disco-test-001 | RUNNING | 172.16.102.11 (eth0) | | PERSISTENT | |
    | disco-test-001 | 실행 중 | 172.16.102.11 (eth0) | | 지속적 | |

    +—————-+———+———————-+——+————+———–+
    | disco-test-002 | RUNNING | 172.16.102.16 (eth0) | | PERSISTENT | |
    | disco-test-002 | 실행 중 | 172.16.102.16 (eth0) | | 지속적 | |

    +—————-+———+———————-+——+————+———–+

    lxc version  lxc 버전
    Client version: 3.13  클라이언트 버전: 3.13
    Server version: 3.13  서버 버전: 3.13

    lxc config show disco-test-002
    architecture: x86_64
    config:
    image.architecture: amd64
    image.description: Ubuntu disco amd64 (20190607_07:42)
    image.os: Ubuntu
    image.release: disco
    image.serial: “20190607_07:42”
    volatile.base_image: fd3f73af851567ca5a4a3083b305a9e4c89fb0e52e74e9da3d095311b36f992b
    volatile.eth0.hwaddr: 00:16:3e:26:84:9a
    volatile.eth0.name: eth0
    volatile.idmap.base: “0”
    volatile.idmap.current: ‘[{“Isuid”:true,”Isgid”:false,”Hostid”:1000000,”Nsid”:0,”Maprange”:1000000000},{“Isuid”:false,”Isgid”:true,”Hostid”:1000000,”Nsid”:0,”Maprange”:1000000000}]’
    volatile.idmap.next: ‘[{“Isuid”:true,”Isgid”:false,”Hostid”:1000000,”Nsid”:0,”Maprange”:1000000000},{“Isuid”:false,”Isgid”:true,”Hostid”:1000000,”Nsid”:0,”Maprange”:1000000000}]’
    volatile.last_state.idmap: ‘[{“Isuid”:true,”Isgid”:false,”Hostid”:1000000,”Nsid”:0,”Maprange”:1000000000},{“Isuid”:false,”Isgid”:true,”Hostid”:1000000,”Nsid”:0,”Maprange”:1000000000}]’
    volatile.last_state.power: RUNNING
    devices:  장치:
    eth0:
    ipv4.address: 172.16.102.33
    nictype: macvlan
    parent: enp3s0.102
    type: nic
    ephemeral: false
    profiles:
    – default  – 기본값
    stateful: false
    description: “”

    1. When you use macvlan, the container’s networking is not managed anymore by LXD (“unmanaged”).
      macvlan을 사용할 때, 컨테이너의 네트워킹은 더 이상 LXD에 의해 관리되지 않습니다 (“비관리”).

      Therefore, commands like “lxc config device set disco-test-002 eth0 ipv4.address 172.16.102.33” have no effect to such containers.
      따라서 "lxc config device set disco-test-002 eth0 ipv4.address 172.16.102.33"와 같은 명령은 이러한 컨테이너에 영향을 미치지 않습니다.

      With macvlan, it is up to you to configure the networking of a container, and LXD cannot do the configuration for you. Having said that, one option to set a static network configuration to a container using macvlan, is to use “cloud-init” in LXD. LXD supports cloud-init configuration, and passes it directly to the container. See me other post on cloud-init.
      macvlan을 사용하면 컨테이너의 네트워킹을 구성하는 것은 당신에게 달려 있으며, LXD가 이를 대신 구성할 수는 없습니다. 그렇긴 하지만, macvlan을 사용하여 컨테이너에 정적 네트워크 구성을 설정하는 한 가지 옵션은 LXD에서 "cloud-init"을 사용하는 것입니다. LXD는 cloud-init 구성을 지원하며, 이를 컨테이너에 직접 전달합니다. cloud-init에 대한 다른 게시물을 참조하세요.

        • Wavex on May 23, 2020 at 09:09
          Wavex 2020년 5월 23일 09:09
        • Reply  답장

        Hi Simos,  안녕 시모스,
        This is a great writeup, and your contribution to opensource is really cool. I’ve got a couple questions, which perhaps you may have answered already somewhere, so please bare with me to ask again.
        이것은 훌륭한 글이며, 당신의 오픈소스에 대한 기여는 정말 멋집니다. 몇 가지 질문이 있는데, 아마 이미 어딘가에서 답변하셨을 수도 있으니 다시 질문하는 것을 양해해 주세요.

        I have a baremetal host that I’m trying to start using lxc/lxd on. It’s running Ubuntu 18.04 and I just initialized lxd on it. I have downloaded a guest ubuntu 16.04 lxc container and trying to assign an IPv6 to it based on macvlan (prefeered) but it seems not to be working.
        나는 lxc/lxd를 사용하려고 하는 베어메탈 호스트가 있습니다. 이 호스트는 Ubuntu 18.04를 실행 중이며, 방금 lxd를 초기화했습니다. 나는 게스트 Ubuntu 16.04 lxc 컨테이너를 다운로드했으며, macvlan(선호됨)을 기반으로 IPv6를 할당하려고 하지만 작동하지 않는 것 같습니다.

        Any leads or step by step guide?
        어떤 단서나 단계별 가이드가 있나요?

        Thank you.  감사합니다.

      1. Thanks!  감사합니다!

        When you use macvlan, then your host appears as yet another system on your LAN. It is good to set it up to get the network configuration from the network, therefore it is your network admin’s issue to set it up. Verify whether you get IPv4 address from the network before investigating an IPv6 address. If you want to set the IPv6 configuration manually, then this is a separate tutorial.
        macvlan 를 사용하면 호스트가 LAN의 또 다른 시스템으로 나타납니다. 네트워크에서 네트워크 구성을 가져오도록 설정하는 것이 좋으므로, 이를 설정하는 것은 네트워크 관리자의 문제입니다. IPv6 주소를 조사하기 전에 네트워크에서 IPv4 주소를 받는지 확인하십시오. IPv6 구성을 수동으로 설정하려면 별도의 튜토리얼이 필요합니다.

  9. Hi, what about case if we run lxd on virtualbox machines (by vagrant) ?
    안녕하세요, 우리가 VirtualBox 머신(바이 Vagrant)에서 lxd를 실행하는 경우는 어떻게 되나요?

    it use nat network for internet access and hostonly network for connect vm machines.
    인터넷 접속을 위해 NAT 네트워크를 사용하고 VM 머신 연결을 위해 호스트 전용 네트워크를 사용합니다.

    I run lxd on first vm, and if i use default network settings with lxdbr0, i have internet connection inside containers, but can’t access to container by ip from another vm in same network
    나는 첫 번째 VM에서 lxd를 실행하고, lxdbr0와 함께 기본 네트워크 설정을 사용하면 컨테이너 내부에서 인터넷 연결이 되지만, 같은 네트워크에 있는 다른 VM에서 IP로 컨테이너에 접근할 수 없습니다

    if i create in vagrant additional private network with dhcp ip resolving (eth2) and define in lxd profile macvlan based on this device – i have access to container ip from another vm, but internet access not available inside containers
    vagrant에서 dhcp ip 해결이 있는 추가 개인 네트워크(eth2)를 생성하고 이 장치를 기반으로 macvlan을 정의하면 다른 vm에서 컨테이너 ip에 접근할 수 있지만 컨테이너 내부에서는 인터넷 접근이 불가능합니다

    1. For testing, it is better to try first without Vagrant. Once you get a working configuration, you can automate with Vagrant.
      테스트를 위해서는 먼저 Vagrant 없이 시도하는 것이 좋습니다. 작동하는 구성을 얻으면 Vagrant로 자동화할 수 있습니다.

      There are several combinations for the networking in VirtualBox virtual machines as shown in the table below,
      다음 표에 표시된 대로 VirtualBox 가상 머신의 네트워킹을 위한 여러 조합이 있습니다

      https://www.thomas-krenn.com/en/wiki/Network_Configuration_in_VirtualBox

      You mention that you have two VirtualBox VMs, both with “Host-only networking”? If that is the case, then according to the table any containers inside these VMs do not have Internet connectivity.
      당신은 두 개의 VirtualBox VM이 있으며, 둘 다 "호스트 전용 네트워킹"이 있다고 언급하셨나요? 그렇다면 표에 따르면 이 VM 내부의 모든 컨테이너는 인터넷 연결이 없습니다.

      I consider the two following scenarios of using LXD with macvlan, inside a VirtualBox virtual machine:
      LXD를 macvlan과 함께 사용하는 두 가지 시나리오를 VirtualBox 가상 머신 내에서 고려합니다:

      1. A VirtualBox virtual machine with “Bridged networking” (it takes an IP address from the LAN), then configure LXD in this VM so that the containers also take IP addresses from the LAN (using macvlan).
        “브리지 네트워킹”이 설정된 VirtualBox 가상 머신(랜에서 IP 주소를 가져옴)을 만든 다음, 이 VM에서 LXD를 구성하여 컨테이너도 랜에서 IP 주소를 가져오도록 설정합니다(맥브랜).
      2. Same as before, but with two Virtualbox virtual machines with same configuration. Have the LXD containers get IP addresses from the LAN, then access each other, the VMs and the Internet.
        이전과 동일하지만 동일한 구성의 두 개의 Virtualbox 가상 머신을 사용합니다. LXD 컨테이너가 LAN에서 IP 주소를 받아 서로, VM 및 인터넷에 접근하도록 합니다.

      For this to work, you need to
      이것이 작동하려면, 당신은 필요합니다

      a1. Set in Virtualbox the Networking to “Bridged networking”.
      a1. Virtualbox에서 네트워킹을 "브리지 네트워킹"으로 설정합니다.

      a2. In the Advanced tab, change the “Promiscuous Mode” setting from “Deny” to “Allow All”. It has to be “Allow All” for this to work.
      a2. 고급 탭에서 "Promiscuous Mode" 설정을 "Deny"에서 "Allow All"로 변경합니다. 작동하려면 "Allow All"이어야 합니다.

      b. Start the VM and setup LXD. Create a LXD profile for macvlan (perhaps edit the “default” profile and add in there there configuration for macvlan.
      b. VM을 시작하고 LXD를 설정합니다. macvlan을 위한 LXD 프로필을 생성합니다(아마도 "기본" 프로필을 편집하고 그곳에 macvlan 구성을 추가합니다).

      c. In the VM, set the network interface into promiscuous mode as well. For example, “sudo ip link set enp0s3 promisc on”.
      c. VM에서 네트워크 인터페이스를 수신 모드로 설정합니다. 예를 들어, “sudo ip link set enp0s3 promisc on”.

      d. Create a LXD container with macvlan configuration. It will be able to get an IP address from your LAN and all will work fine.
      d. macvlan 구성으로 LXD 컨테이너를 생성합니다. LAN에서 IP 주소를 받을 수 있으며 모든 것이 잘 작동할 것입니다.

      e. Repeat with multiple VMs. The LXD containers will be able to access each other, the LAN, the VMs and the Internet.
      e. 여러 VM으로 반복합니다. LXD 컨테이너는 서로, LAN, VM 및 인터넷에 접근할 수 있습니다.

      1. Thanks for reply. So internet access from containers inside VM possible only with bridged vagrant mode, and there are no way to create any additional ip rules inside VM for containers?
        답변 감사합니다. 따라서 VM 내부의 컨테이너에서 인터넷에 접근하려면 브리지드 베이그런트 모드만 가능하며, VM 내부에서 컨테이너를 위한 추가 IP 규칙을 생성할 방법이 없습니까?

        And also one moment, internet access for my work machine provided by router, i have static ip, not dhcp mode
        그리고 또한 잠시, 내 작업용 컴퓨터의 인터넷 접속은 라우터에 의해 제공되며, 나는 정적 IP를 사용하고 DHCP 모드가 아닙니다

      2. for clear explanation, i don’t need access from internet to containers, only from containers to internet. And network example – green lines – ping success, red – failed https://drive.google.com/file/d/1X92O94P1hxGkWMulTq1_tqOXFqErWvnQ/view?usp=sharing
        명확한 설명을 위해, 저는 컨테이너에서 인터넷으로의 접근만 필요하고, 인터넷에서 컨테이너로의 접근은 필요하지 않습니다. 그리고 네트워크 예시 - 초록색 선 - 핑 성공, 빨간색 - 실패 https://drive.google.com/file/d/1X92O94P1hxGkWMulTq1_tqOXFqErWvnQ/view?usp=sharing

      3. According to the table at https://www.thomas-krenn.com/en/wiki/Network_Configuration_in_VirtualBox#Network_Address_Translation_Service
        https://www.thomas-krenn.com/en/wiki/Network_Configuration_in_VirtualBox#Network_Address_Translation_Service에 있는 표에 따르면

        there are three different network settings for the VM (therefore, the containers) to access the Internet. See the column “Access Guest -> external Network”.
        VM(따라서 컨테이너)가 인터넷에 접근하기 위한 세 가지 다른 네트워크 설정이 있습니다. "Access Guest -> external Network" 열을 참조하십시오.

        It is OK if your work machine is assigned a static IP. If there is no DHCP server, then you would have to setup manually the networking of each “macvlan” container.
        작업 머신에 정적 IP가 할당되어도 괜찮습니다. DHCP 서버가 없으면 각 "macvlan" 컨테이너의 네트워킹을 수동으로 설정해야 합니다.

        In the network diagram, VM1 is using NAT networking. Which means that the VM is not accessible directly by the LXD containers of VM2.
        네트워크 다이어그램에서 VM1은 NAT 네트워킹을 사용하고 있습니다. 이는 VM이 VM2의 LXD 컨테이너에 의해 직접 접근할 수 없음을 의미합니다.

  10. Thanks a lot! It was very helpful!
    정말 감사합니다! 매우 도움이 되었습니다!

  11. Hi Simos,  안녕 시모스,

    Thanks for the instructions provided above! I’ve followed them to the letter on several machines, but consistently see the same problem: my interface is consistently dropping packets.
    위에 제공된 지침에 감사드립니다! 여러 대의 기계에서 이를 철저히 따랐지만, 항상 같은 문제를 보고 있습니다: 내 인터페이스가 지속적으로 패킷을 드롭하고 있습니다.

    I’m referring to the host’s interface. The interface consistently drops 1 packet, roughly every 30 seconds. I have tested this with multiple containers running, but the packet loss remains constant (no increase with more containers).
    호스트의 인터페이스를 언급하고 있습니다. 인터페이스는 대략 30초마다 1개의 패킷을 지속적으로 드롭합니다. 여러 개의 컨테이너를 실행하여 테스트했지만 패킷 손실은 일정하게 유지됩니다(더 많은 컨테이너로 증가하지 않음).

    I’ve tested this in both ubuntu 16.04 and 18.04 across 3 different hosts, both have the same result. This happens whether the interface is in promiscuous mode or not.
    나는 이것을 3개의 서로 다른 호스트에서 우분투 16.04와 18.04 모두에서 테스트했으며, 두 경우 모두 동일한 결과가 나왔다. 인터페이스가 프로미스큐어스 모드인지 여부에 관계없이 이 문제가 발생한다.

    Do you have any idea what the cause could be?
    원인이 무엇일지 아세요?

    1. Hi Nathan,  안녕, 네이선

      I have not noticed this issue. I suspect it would be a Linux kernel issue.
      이 문제를 눈치채지 못했습니다. 리눅스 커널 문제일 것이라고 의심합니다.

      Can you post some instructions on how to automate this check of the dropped packet?
      드롭된 패킷의 이 검사를 자동화하는 방법에 대한 지침을 게시해 주실 수 있나요?

      It would be good to be able to replicate before reporting.
      보고하기 전에 복제할 수 있으면 좋겠습니다.

        • Nathan on October 7, 2019 at 09:06
          Nathan 2019년 10월 7일 09:06
        • Reply  답장

        Hi Simos,  안녕 시모스,

        Thanks for your response. I’ve put together a quick way to monitor the issue this morning:
        답변해 주셔서 감사합니다. 오늘 아침에 문제를 모니터링할 수 있는 간단한 방법을 마련했습니다:

        #!/bin/bash
        interface=$1
        
        while true; do
                echo "$(date +%F\ %T%z) | $interface -- $(ifconfig "$interface" | grep 'RX packets' | sed 's/  */ /g' | cut -d' ' -f4)"
                sleep 2
        
            read -t 0.25 -N 1 input
            if [ "$input" = 'q' -o "$input" = 'Q' ]; then
                    break
            fi
        
        
        done
        

        The name of the interface being monitored should be supplied as an argument.
        모니터링되는 인터페이스의 이름은 인수로 제공되어야 합니다.

        The kernel releases that I’ve tested this on are ‘4.4.0-112-generic’ and ‘5.0.0-29-generic’ on Ubuntu 16.04.5 and 18.04.3 respectively.
        제가 이 테스트를 수행한 커널 릴리스는 각각 Ubuntu 16.04.5와 18.04.3에서 '4.4.0-112-generic'과 '5.0.0-29-generic'입니다.

      1. Thanks!  감사합니다!

        There is a tool, dropwatch, at https://github.com/nhorman/dropwatch which may show some extra information on the cause of the packet drop.
        패킷 손실의 원인에 대한 추가 정보를 보여줄 수 있는 도구인 dropwatch가 https://github.com/nhorman/dropwatch에 있습니다.

        I tried with Linux 4.15 but could not replicate (see dropped packets in ifconfig output of the host’s interface, when a container was using the macvlan over that interface).
        나는 Linux 4.15로 시도했지만 재현할 수 없었다 (컨테이너가 해당 인터페이스에서 macvlan을 사용할 때 호스트의 인터페이스에서 ifconfig 출력의 드롭된 패킷을 참조).

        • Nathan on October 8, 2019 at 09:31
          Nathan 2019년 10월 8일 09:31
        • Reply  답장

        Hi Simos,  안녕 시모스,

        Thanks for looking into this. Unfortunately, dropwatch hasn’t yielded any helpful information: I get long lists of ‘dropped packets’ whether packets are being dropped or not. The lists are similar and cover the same range of addresses regardless of whether packets are being dropped or not.
        이 문제를 살펴봐 주셔서 감사합니다. 불행히도, 드롭워치에서는 유용한 정보를 얻지 못했습니다: 패킷이 드롭되든 아니든 '드롭된 패킷'의 긴 목록이 나옵니다. 목록은 비슷하고 패킷이 드롭되든 아니든 동일한 주소 범위를 포함합니다.

        I will continue to investigate and update you if I find the source of the problem.
        문제의 원인을 찾으면 계속 조사하고 업데이트하겠습니다.

  12. Thank you for the write up. But I wonder if I (or perhaps) you missed something. In the intro, you outline that “we launch new containers under the new profile, or attach existing containers to the new profile”. But I don’t see the bit were we attach existing containers to the new profile. Could you show me how I would do that?
    작성해 주셔서 감사합니다. 하지만 제가 (혹은 아마도) 뭔가를 놓쳤는지 궁금합니다. 서두에서 "우리는 새로운 프로필 아래에 새로운 컨테이너를 시작하거나 기존 컨테이너를 새로운 프로필에 연결합니다"라고 설명하셨습니다. 하지만 기존 컨테이너를 새로운 프로필에 연결하는 부분이 보이지 않습니다. 제가 어떻게 해야 하는지 보여주실 수 있나요?

    Thanks.  감사합니다.

    –wpd

    1. Thanks!  감사합니다!

      Here you go. You use lxc profile assign to assign a new set of profiles to an existing container. Previously, this subcommand used to be “attach”. Now, it’s assign.
      여기 있습니다. lxc profile assign 를 사용하여 기존 컨테이너에 새로운 프로필 세트를 할당합니다. 이전에는 이 하위 명령이 "attach"였습니다. 이제는 assign입니다.

      $ lxc launch ubuntu:18.04 mycontainer
      Creating mycontainer
      Starting mycontainer
      $ lxc list mycontainer
      +-------------+---------+---------------------+------+------------+-----------+
      |    NAME     |  STATE  |        IPV4         | IPV6 |    TYPE    | SNAPSHOTS |
      +-------------+---------+---------------------+------+------------+-----------+
      | mycontainer | RUNNING | 10.10.10.222 (eth0) |      | PERSISTENT | 0         |
      +-------------+---------+---------------------+------+------------+-----------+
      $ lxc profile assign mycontainer default,macvlan
      Profiles default,macvlan applied to mycontainer
      $ lxc list mycontainer
      +-------------+---------+------+------+------------+-----------+
      |    NAME     |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
      +-------------+---------+------+------+------------+-----------+
      | mycontainer | RUNNING |      |      | PERSISTENT | 0         |
      +-------------+---------+------+------+------------+-----------+
      $ lxc restart mycontainer
      $ lxc list mycontainer
      +-------------+---------+--------------------+------+------------+-----------+
      |    NAME     |  STATE  |        IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
      +-------------+---------+--------------------+------+------------+-----------+
      | mycontainer | RUNNING | 192.168.1.9 (eth0) |      | PERSISTENT | 0         |
      +-------------+---------+--------------------+------+------------+-----------+
      $ 
      
      
  13. Simos,

    Have you seen this error before?
    이 오류를 전에 본 적이 있나요?

    Error: Device validation failed “eth0”: Cannot use “nictype” property in conjunction with “network” property
    오류: 장치 검증 실패 “eth0”: “network” 속성과 함께 “nictype” 속성을 사용할 수 없습니다

    I posted a write up with my own experience of deploying Macvlan & LXD (see https://blog.plip.com/2019/08/17/nat-and-macvlan-on-production-lxd-plus-reverse-proxy-ssh-config/) and some users are coming across this error when then run this command:
    나는 Macvlan 및 LXD 배포에 대한 나의 경험을 담은 글을 게시했습니다(https://blog.plip.com/2019/08/17/nat-and-macvlan-on-production-lxd-plus-reverse-proxy-ssh-config/ 참조) 그리고 일부 사용자들이 이 명령을 실행할 때 이 오류에 직면하고 있습니다:

    lxc profile device set lanprofile eth0 nictype macvlan

    While I’ve tried to reproduce the error, I haven’t been able to. I thought I might reach out because I feel you seem to have a much stronger grasp of this stuff than I do. I suspected maybe newer versions of LXD are causing it, but I’ve been unable to confirm.
    오류를 재현해 보려고 했지만, 할 수 없었습니다. 제가 이 문제에 대해 당신이 저보다 훨씬 더 잘 알고 있는 것 같아서 연락을 드리려고 했습니다. LXD의 최신 버전이 원인일 수 있다고 의심했지만, 확인할 수 없었습니다.

    Much thanks!!  대단히 감사합니다!!

    1. Hi mrjones!  안녕하세요 mrjones!

      You can show the profile with lxc profile show lanprovile in order to have an idea on what is in there.
      lxc profile show lanprovile 를 사용하여 그 안에 무엇이 있는지에 대한 아이디어를 얻을 수 있습니다.

      Such an error should be easy to diagnose, because you just need to copy the profile content in order to replicate.
      이런 오류는 진단하기 쉬워야 합니다. 왜냐하면 복제를 위해 프로필 내용을 복사하기만 하면 되기 때문입니다.

        • Chriss_france on June 22, 2020 at 18:51
          Chriss_france 2020년 6월 22일 18:51
        • Reply  답장

        Hello,  안녕하세요,
        The problem that I encounter and that mrjones transmitted to you is the impossibility of following this tutorial:
        제가 겪고 있는 문제와 mrjones가 당신에게 전달한 것은 이 튜토리얼을 따를 수 없다는 것입니다:

        https://blog.simos.info/how-to-make-your-lxd-container-get-ip-addresses-from-your-lan/

        There may be some prerequisites that have not been mentioned in this one.
        이것에서 언급되지 않은 몇 가지 전제 조건이 있을 수 있습니다.

        I have a fresh install of Ubuntu Server 20.04 amd64 and lxc 4.2

      1. You are both right. The syntax in lxc profile device add has changed in a recent version of LXD and the old syntax was supposed to work in a compatibility mode. However, in LXD 4.2 (at least) it gives the error that mrjones show above.
        당신 둘 다 맞습니다. lxc profile device add 의 구문은 최근 LXD 버전에서 변경되었고, 이전 구문은 호환 모드에서 작동해야 했습니다. 그러나 LXD 4.2(최소한)에서는 mrjones가 위에 보여준 오류가 발생합니다.

        If you get any other errors, please post the exact command that gives you these errors.
        다른 오류가 발생하면, 이러한 오류를 발생시키는 정확한 명령어를 게시해 주세요.

        By making these changes, it is likely that older versions of LXD may not be working. I do not know when the format changed, so it is up to you to notify me! 🙂
        이러한 변경을 함으로써 이전 버전의 LXD가 작동하지 않을 가능성이 있습니다. 형식이 언제 변경되었는지 모르므로, 저에게 알려주는 것은 당신에게 달려 있습니다! 🙂

  14. Hello,  안녕하세요,
    I have problem with CentOS is not give me a network
    CentOS가 네트워크를 제공하지 않는 문제입니다

    but with Ubuntu it work fine
    하지만 Ubuntu에서는 잘 작동합니다

    I don’t know what a problem is
    문제가 무엇인지 모르겠습니다

    could you please help
    도와주실 수 있나요?

  15. root@ubuntu:~# lxc list
    +--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
    |  NAME  |  STATE  |        IPV4         |                     IPV6                      |   TYPE    | SNAPSHOTS |
    +--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
    +--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
    | net1   | RUNNING |                     |                                               | CONTAINER | 0         |
    +--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
    | net2   | RUNNING |                     |                                               | CONTAINER | 0         |
    +--------+---------+---------------------+-----------------------------------------------+-----------+-----------+
    root@ubuntu:~#
    root@ubuntu:~# lxc profile list
    +---------+---------+
    |  NAME   | USED BY |
    +---------+---------+
    | default | 3       |
    +---------+---------+
    | macvlan | 2       |
    +---------+---------+
    root@ubuntu:~#
    root@ubuntu:~# lxc p
    pause    profile  project  publish
    root@ubuntu:~# lxc profile show macvlan
    config: {}
    description: ""
    devices:
      eth0:
        nictype: macvlan
        parent: ens33
        type: nic
    name: macvlan
    used_by:
    - /1.0/instances/net1
    - /1.0/instances/net2
    root@ubuntu:~#
    root@ubuntu:~# lxc profile show default
    config: {}
    description: Default LXD profile
    devices:
      eth0:
        name: eth0
        network: lxdbr0
        type: nic
      root:
        path: /
        pool: default
        type: disk
    name: default
    used_by:
    - /1.0/instances/Cent01
    - /1.0/instances/net1
    - /1.0/instances/net2
    
  16. Hi!  안녕하세요!

    Can you show a full example that demonstrates that the same LXD profile for macvlan works for an Ubuntu container but does not work with a Centos container?
    Ubuntu 컨테이너에서 작동하지만 Centos 컨테이너에서는 작동하지 않는 동일한 LXD 프로필에 대한 전체 예제를 보여줄 수 있나요?

    1. Show the profile content.
      프로필 내용을 보여주세요.
    2. Create an Ubuntu container with that profile
      해당 프로필로 Ubuntu 컨테이너를 생성하세요
    3. Create a Centos container with that profile
      해당 프로필로 Centos 컨테이너를 생성하세요
    4. Wait a minute or so to make sure that they both booted up.
      잠시 기다려서 두 대 모두 부팅되었는지 확인하세요.
    5. Run lxc list so that we can see that the Ubuntu container got an IP address but the other did not.

    Such a reproducible set of instructions would be easy for me to try, and can escalate to the proper place to get it fixed.
    이러한 재현 가능한 지침 세트는 제가 시도하기 쉽고, 문제를 해결하기 위해 적절한 곳으로 escalade할 수 있습니다.

  17. thank for reply,  답변해 주셔서 감사합니다,

    now i can config ip for container but container can’t ping to own gateway like this:

    My ip I set  내가 설정한 IP
    My lxd host: 10.2.17.135 (ubuntu20)
    Container1: 10.2.17.15 (Centos7)
    Container2: 10.2.17.16 (Centos7)

    Container1 can ping Container2 but can’t ping to My lxd host and it own gateway(10.2.17.1)
    Container1은 Container2에 핑을 보낼 수 있지만 My lxd 호스트와 자신의 게이트웨이(10.2.17.1)에는 핑을 보낼 수 없습니다.

    10.2.17.15 can ping 10.2.17.16 but can’t ping to 10.2.17.135 or 10.2.17.1
    10.2.17.15는 10.2.17.16에 핑을 보낼 수 있지만 10.2.17.135나 10.2.17.1에는 핑을 보낼 수 없습니다.

  18. Hi, I’ve got a problem with Centos 8. Centos 7, Fedora and Ubuntu containers are getting the IP properly, Centos 8 and Centos Stream don’t get the IP.
    안녕하세요, Centos 8에 문제가 있습니다. Centos 7, Fedora 및 Ubuntu 컨테이너는 IP를 제대로 받지만, Centos 8과 Centos Stream은 IP를 받지 못합니다.

    1. This has been addressed here, https://discuss.linuxcontainers.org/t/1-6-lxd-containers-not-assigned-ipv4-ipv6-addresses/9687
      이것은 여기에서 다루어졌습니다, https://discuss.linuxcontainers.org/t/1-6-lxd-containers-not-assigned-ipv4-ipv6-addresses/9687

      The Centos 8 Stream container image did not get automatically upon starting an IP address from the default network setup, and it has just been fixed.
      Centos 8 Stream 컨테이너 이미지가 기본 네트워크 설정에서 IP 주소를 시작할 때 자동으로 가져오지 않았으며, 이제 수정되었습니다.

      If you have cached a Centos 8 container image, you may need to delete it first.
      Centos 8 컨테이너 이미지를 캐시한 경우, 먼저 삭제해야 할 수 있습니다.

      $ lxc image list
      +------------+--------------+--------+----------------------------------------------------+--------------+-----------------+----------+-------------------------------+
      |   ALIAS    | FINGERPRINT  | PUBLIC |                    DESCRIPTION                     | ARCHITECTURE |      TYPE       |   SIZE   |          UPLOAD DATE          |
      +------------+--------------+--------+----------------------------------------------------+--------------+-----------------+----------+-------------------------------+
      |            | c5f02659eaca | no     | Centos 8-Stream amd64 (20201216_07:08)             | x86_64       | CONTAINER       | 126.81MB | Dec 16, 2020 at 5:31pm (UTC)  |
      +------------+--------------+--------+----------------------------------------------------+--------------+-----------------+----------+-------------------------------+
      $ lxc image delete c5f02659eaca
      $ lxc launch images:centos/8-Stream centos8stream
      $ lxc list centos8stream
      +---------------+---------+---------------------+------+-----------+-----------+
      |     NAME      |  STATE  |        IPV4         | IPV6 |   TYPE    | SNAPSHOTS |
      +---------------+---------+---------------------+------+-----------+-----------+
      | centos8stream | RUNNING | 10.10.10.120 (eth0) |      | CONTAINER | 0         |
      +---------------+---------+---------------------+------+-----------+-----------+
      $ 
      

      You mention that CentOS 8 has an issue as well. Please verify and report back so that it gets fixed as well.
      CentOS 8에도 문제가 있다고 언급하셨습니다. 확인하시고 보고해 주시면 수정될 수 있도록 하겠습니다.

  19. Hi Sir.  안녕하세요, 선생님.

    I have tried the steps above but when creating the container I did not get the IP details as follows:
    위의 단계를 시도했지만 컨테이너를 생성할 때 다음과 같은 IP 세부정보를 얻지 못했습니다:

    ubuntu@lxd-belajarlinux:~$
    ubuntu@lxd-belajarlinux:~$ lxc profile create macvlan
    Profile macvlan created
    ubuntu@lxd-belajarlinux:~$ lxc profile list
    +---------+---------+
    |  NAME   | USED BY |
    +---------+---------+
    | default | 1       |
    +---------+---------+
    | macvlan | 0       |
    +---------+---------+
    ubuntu@lxd-belajarlinux:~$ lxc profile show macvlan
    config: {}
    description: ""
    devices: {}
    name: macvlan
    used_by: []
    ubuntu@lxd-belajarlinux:~$ ip route show default 0.0.0.0/0
    default via 10.36.36.1 dev ens3 proto dhcp src 10.36.36.5 metric 100
    ubuntu@lxd-belajarlinux:~$
    ubuntu@lxd-belajarlinux:~$ lxc profile device add macvlan eth0 nic nictype=macvlan parent=ens3
    Device eth0 added to macvlan
    ubuntu@lxd-belajarlinux:~$
    ubuntu@lxd-belajarlinux:~$ lxc profile show macvlan
    config: {}
    description: ""
    devices:
      eth0:
        nictype: macvlan
        parent: ens3
        type: nic
    name: macvlan
    used_by: []
    ubuntu@lxd-belajarlinux:~$ lxc launch ubuntu:18.04 net1 --profile default --profile macvlan
    Creating net1
    Starting net1
    ubuntu@lxd-belajarlinux:~$ lxc launch ubuntu:18.04 net2 --profile default --profile macvlan
    Creating net2
    Starting net2
    ubuntu@lxd-belajarlinux:~$ lxc list
    +------+---------+----------------------+----------------------------------------------+-----------+-----------+
    | NAME |  STATE  |         IPV4         |                     IPV6                     |   TYPE    | SNAPSHOTS |
    +------+---------+----------------------+----------------------------------------------+-----------+-----------+
    | net1 | RUNNING |                      |                                              | CONTAINER | 0         |
    +------+---------+----------------------+----------------------------------------------+-----------+-----------+
    | net2 | RUNNING |                      |                                              | CONTAINER | 0         |
    +------+---------+----------------------+----------------------------------------------+-----------+-----------+
    | wtf  | RUNNING | 10.228.25.102 (eth0) | fd42:c1d4:8f3:fa13:216:3eff:fe3c:56a9 (eth0) | CONTAINER | 0         |
    +------+---------+----------------------+----------------------------------------------+-----------+-----------+
    ubuntu@lxd-belajarlinux:~$
    

    Is there something wrong?.
    무언가 잘못되었나요?

    Thank you for the advice
    조언해 주셔서 감사합니다

  20. Hi!  안녕하세요!

    Is there a VM involved with the ens3 network interface? If there is KVM or something similar, then they may be breaking macvlan.
    ens3 네트워크 인터페이스에 VM이 관련되어 있습니까? KVM 또는 유사한 것이 있다면, 그들은 macvlan 를 방해할 수 있습니다.

  21. Unfortunately, it still doesn’t work 🙁
    안타깝게도 여전히 작동하지 않습니다 🙁

    [root@lxd1 ~]# lxc ls
    +------+-------+------+------+------+-----------+----------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
    +------+-------+------+------+------+-----------+----------+
    [root@lxd1 ~]# lxc image ls
    +-------+-------------+--------+-------------+--------------+------+------+-------------+
    | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
    +-------+-------------+--------+-------------+--------------+------+------+-------------+
    [root@lxd1 ~]# lxc launch images:centos/8-Stream stream --profile default --profile macvlan
    Creating stream
    Starting stream
    [root@lxd1 ~]# lxc ls
    +--------+---------+------+------+-----------+-----------+------------------------------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
    +--------+---------+------+------+-----------+-----------+------------------------------+
    | stream | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +--------+---------+------+------+-----------+-----------+------------------------------+
    [root@lxd1 ~]# lxc launch images:centos/8 centos80 --profile default --profile macvlan
    Creating centos80
    Starting centos80
    [root@lxd1 ~]# lxc ls
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | centos80 | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | stream | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    [root@lxd1 ~]# lxc launch images:centos/7 centos7 --profile default --profile macvlan
    Creating centos7
    Starting centos7
    [root@lxd1 ~]# lxc ls
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | centos7 | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | centos80 | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | stream | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    [root@lxd1 ~]# lxc ls
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | centos7 | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | centos80 | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    | stream | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+------+------+-----------+-----------+------------------------------+
    [root@lxd1 ~]# lxc ls
    +----------+---------+--------------------+------+-----------+-----------+------------------------------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | LOCATION |
    +----------+---------+--------------------+------+-----------+-----------+------------------------------+
    | centos7 | RUNNING | 10.10.1.127 (eth0) | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+--------------------+------+-----------+-----------+------------------------------+
    | centos80 | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+--------------------+------+-----------+-----------+------------------------------+
    | stream | RUNNING | | | CONTAINER | 0 | lxd1.-redacted- |
    +----------+---------+--------------------+------+-----------+-----------+------------------------------+
    [root@lxd1 ~]# lxc image ls
    +-------+--------------+--------+----------------------------------------+--------------+-----------+----------+-------------------------------+
    | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
    +-------+--------------+--------+----------------------------------------+--------------+-----------+----------+-------------------------------+
    | | 10504755901f | no | Centos 7 amd64 (20201217_07:08) | x86_64 | CONTAINER | 83.41MB | Dec 17, 2020 at 10:14am (UTC) |
    +-------+--------------+--------+----------------------------------------+--------------+-----------+----------+-------------------------------+
    | | ad35b15ede2d | no | Centos 8 amd64 (20201217_07:08) | x86_64 | CONTAINER | 125.56MB | Dec 17, 2020 at 10:13am (UTC) |
    +-------+--------------+--------+----------------------------------------+--------------+-----------+----------+-------------------------------+
    | | b26773ad0a9b | no | Centos 8-Stream amd64 (20201217_07:08) | x86_64 | CONTAINER | 126.81MB | Dec 17, 2020 at 10:12am (UTC) |
    +-------+--------------+--------+----------------------------------------+--------------+-----------+----------+-------------------------------+

  22. Outstandingly useful, worked first time. THANK YOU VERY MUCH.
    매우 유용하고, 처음부터 잘 작동했습니다. 정말 감사합니다.

  23. is there any way to get this running for wireless interface
    무선 인터페이스에서 이것을 실행할 방법이 있나요?

  24. You can use ipvlan or routed in order to make this (assigning a LAN IP address to the container) work.
    이 작업을 수행하려면 ipvlan 또는 routed 을 사용할 수 있습니다 (컨테이너에 LAN IP 주소 할당).

    Here is the tutorial with routed, https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/
    여기 routed 와 함께하는 튜토리얼이 있습니다, https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/

  25. tx for the reply, i tried with routed network it worked but was not able to internet from container (like ping google.com) but other hosts are reachable from the container.
    답변 감사합니다. 라우팅된 네트워크로 시도해봤는데 작동했지만 컨테이너에서 인터넷에 연결할 수는 없었습니다(예: google.com에 핑). 하지만 다른 호스트는 컨테이너에서 접근 가능합니다.

  26. Most probably you had DNS issues. Can you tell me which Linux runs on the host and which in the container? Also, the host is baremetal or some virtualization platform?
    대부분 아마 DNS 문제가 있었던 것 같습니다. 호스트에서 어떤 리눅스가 실행되고 있고, 컨테이너에서는 어떤 리눅스가 실행되고 있는지 말씀해 주실 수 있나요? 또한, 호스트는 베어메탈인가요, 아니면 어떤 가상화 플랫폼인가요?

  27. My host machine is not a VM, it is a bare metal box and it is running with ubuntu 20.04
    내 호스트 머신은 VM이 아니며, 베어 메탈 박스이고 우분투 20.04로 실행되고 있습니다.

    ~ lxc list
    +------+---------+----------------------+------+-----------+-----------+
    | NAME |  STATE  |         IPV4         | IPV6 |   TYPE    | SNAPSHOTS |
    +------+---------+----------------------+------+-----------+-----------+
    | u1   | RUNNING | 192.168.1.200 (eth0) |      | CONTAINER | 0         |
    +------+---------+----------------------+------+-----------+-----------+
    
    ~ lxc exec u1 bash
    

    This is inside the container host machine is reachable
    컨테이너 호스트 머신 내부에 있습니다

    root@u1:~# ping 192.168.1.36 
    PING 192.168.1.36 (192.168.1.36) 56(84) bytes of data.
    64 bytes from 192.168.1.36: icmp_seq=1 ttl=64 time=0.116 ms
    64 bytes from 192.168.1.36: icmp_seq=2 ttl=64 time=0.069 ms
    --- 192.168.1.36 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1027ms
    rtt min/avg/max/mdev = 0.069/0.092/0.116/0.023 ms
    

    This is inside the container google.com is not reachable
    이것은 컨테이너 내부입니다 google.com에 접근할 수 없습니다.

    root@u1:~# ping google.com
    ping: google.com: Temporary failure in name resolution
    
      • panwolfram on January 27, 2021 at 11:23
        panwolfram 2021년 1월 27일 11:23
      • Reply  답장

      Does it ping 1.1.1.1 ?
      1.1.1.1에 핑이 가나요?

  28. Are you still trying to get macvlan to work over a wireless interface? The only way it might work is if you disable any wireless security on the access point (i.e. disable WPA/WPA2/WEP), because the access point should be in a position to accept two distinct MAC addresses from the same single host.
    여전히 macvlan 를 무선 인터페이스에서 작동시키려고 하고 있나요? 작동할 수 있는 유일한 방법은 액세스 포인트에서 모든 무선 보안을 비활성화하는 것입니다(즉, WPA/WPA2/WEP 비활성화), 왜냐하면 액세스 포인트는 동일한 단일 호스트에서 두 개의 서로 다른 MAC 주소를 수용할 수 있는 위치에 있어야 하기 때문입니다.

    If you are using routed or ipvlan, please say so.
    routed 또는 ipvlan 을(를) 사용하고 있다면, 그렇게 말씀해 주세요.

    It would help if you show us the LXD profile(s) when you create u1. Because you might have two network interfaces in the container, and one of them is the standard one attached to lxdbr0, hence access to other LXD containers.
    u1 를 생성할 때 LXD 프로필을 보여주시면 도움이 될 것입니다. 컨테이너에 두 개의 네트워크 인터페이스가 있을 수 있으며, 그 중 하나는 lxdbr0 에 연결된 표준 인터페이스이므로 다른 LXD 컨테이너에 접근할 수 있습니다.

  29. My profile config  내 프로필 구성

    lxc profile show routed
    config:
      user.network-config: |
        version: 2
        ethernets:
            eth0:
                addresses:
                - 192.168.1.200/24
                nameservers:
                    addresses:
                    - 8.8.8.8
                    search: []
                routes:
                -   to: 0.0.0.0/0
                    via: 169.254.0.1
                    on-link: true
    description: Default LXD profile
    devices:
      eth0:
        ipv4.address: 192.168.1.200
        nictype: routed
        parent: wlp3s0
        type: nic
    name: routed
    used_by:
    - /1.0/instances/u1
    
  30. lxc list
    +——+———+———————-+——+———–+———–+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
    +——+———+———————-+——+———–+———–+
    | u1 | RUNNING | 192.168.1.200 (eth0) | | CONTAINER | 0 |
    | u1 | 실행 중 | 192.168.1.200 (eth0) | | 컨테이너 | 0 |

    +——+———+———————-+——+———–+———–+

    lxc exec u1 bash
    root@u1:~# ip link
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: eth0@if28: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 9a:0e:27:a5:33:d9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    root@u1:~#

  31. yes
    root@u1:~# ping 1.1.1.1
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=1001 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=102 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=23.5 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=46.3 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=56 time=70.8 ms
    
  32. config:
      user.network-config: |
        version: 2
        ethernets:
            eth0:
                addresses:
                - 192.168.1.200/24
                nameservers:
                    addresses:
                    - 8.8.8.8
                    search: []
                routes:
                -   to: 0.0.0.0/0
                    via: 169.254.0.1
                    on-link: true
    description: Default LXD profile
    devices:
      eth0:
        ipv4.address: 192.168.1.200
        nictype: routed
        parent: wlp3s0
        type: nic
    name: routed
    used_by:
    - /1.0/instances/u1
    
  33. You are using routed in this setup while this post is about macvlan. Can you post a comment under https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/ ?
    이 설정에서 routed 를 사용하고 있으며 이 게시물은 macvlan 에 관한 것입니다. https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/ 아래에 댓글을 남길 수 있나요?

    You can post your LXD profile (this last comment), and mention that name resolution (DNS) has not been configured even if it has been specified in the LXD profile.
    LXD 프로필(이 마지막 댓글)을 게시할 수 있으며, LXD 프로필에 지정되었더라도 이름 해상도(DNS)가 구성되지 않았다고 언급할 수 있습니다.

  34. I already have 2 containers which configured as NAT. I’ve tried to add new profile by
    나는 이미 NAT로 구성된 2개의 컨테이너가 있습니다. 새로운 프로필을 추가하려고 시도했습니다.

    lxc profile add net1 macvlan
    but then it can’t get any IP and internet doesn’t work anymore.
    하지만 그럼 IP를 받을 수 없고 인터넷이 더 이상 작동하지 않습니다.

    How can I add new macvlan profiles to my existing containers?
    기존 컨테이너에 새로운 macvlan 프로필을 어떻게 추가할 수 있나요?

  35. Hi!  안녕하세요!

    The default LXD profile has the default network configuration for the container to use private bridge networking. It looks like this:
    기본 LXD 프로필은 컨테이너가 개인 브리지 네트워킹을 사용할 수 있도록 기본 네트워크 구성을 가지고 있습니다. 다음과 같습니다:

    $ lxc profile show default
    ...
    devices:
    eth0:
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
    ...
    $

    If you use the macvlan profile in this post as is, then it has its own section for eth0 as follows:
    이 게시물에서 macvlan 프로필을 그대로 사용하면 eth0 에 대한 자체 섹션이 다음과 같이 있습니다:

    $ lxc profile show macvlan
    ...
    devices:
    eth0:
    nictype: macvlan
    parent: enp3s0
    type: nic
    ...
    $

    Therefore, if you launch a container using the default profile, and then add the macvlan profile, the container will end up losing the eth0/bridged and it will be replaced with eth0/macvlan. Because both network interfaces have the same name.
    따라서 default 프로필을 사용하여 컨테이너를 시작한 다음 macvlan 프로필을 추가하면 컨테이너는 eth0/bridged 를 잃게 되고 eth0/macvlan 로 대체됩니다. 두 네트워크 인터페이스의 이름이 동일하기 때문입니다.

    All in all, if you want your containers to have both network interfaces, then edit your macvlan profile so that the network interface does not have the same name as in the default profile.
    결론적으로, 컨테이너에 두 개의 네트워크 인터페이스가 필요하다면 macvlan 프로필을 수정하여 네트워크 인터페이스의 이름이 default 프로필과 동일하지 않도록 하십시오.

    To answer your initial question that your containers lose network connectivity when you apply the macvlan profile; most likely LXD runs in a VM (macvlan may not work in such a case) or you have a WiFi interface for the networking of your host (WiFi networking with WEP/WPA/WPA2 is not compatible with macvlan).
    당신의 초기 질문에 답하기 위해, macvlan 프로필을 적용할 때 컨테이너가 네트워크 연결을 잃는 이유는 LXD가 VM에서 실행되고 있기 때문일 가능성이 높습니다 (이 경우 macvlan 이 작동하지 않을 수 있습니다) 또는 호스트의 네트워킹을 위해 WiFi 인터페이스가 있습니다 (WEP/WPA/WPA2가 있는 WiFi 네트워킹은 macvlan 와 호환되지 않습니다).

    • Alexei on February 13, 2021 at 04:34
      Alexei 2021년 2월 13일 04:34
    • Reply  답장

    Thank you for the excellent tutorial Simos. I very much appreciate the time you took to explain the basic concepts. The world of containers is new to me and I was finding it extremely difficult to get good resources that actually explain the concepts. Now thanks to your tutorial I can configure my container just the way I want.
    훌륭한 튜토리얼 감사합니다, Simos. 기본 개념을 설명하는 데 시간을 내주셔서 정말 감사드립니다. 컨테이너의 세계는 저에게 새롭고, 개념을 실제로 설명하는 좋은 자료를 찾는 것이 매우 어려웠습니다. 이제 당신의 튜토리얼 덕분에 원하는 대로 컨테이너를 구성할 수 있게 되었습니다.

    1. Many thanks Alexei for your kind words!
      친절한 말씀 감사합니다, 알렉세이!

  36. Interesting….  흥미롭군요….
    I’m searching a way to do the same, but with static public IPs.
    나는 정적 공인 IP로 동일한 작업을 수행할 방법을 찾고 있습니다.

    Currently I have enp35s0 with 4 public IPs assigned to it, and 3 LXD containers and I want each container to use one of the public IPs.
    현재 저는 enp35s0 에 4개의 공인 IP가 할당되어 있고, 3개의 LXD 컨테이너가 있으며 각 컨테이너가 공인 IP 중 하나를 사용하기를 원합니다.

    Simox Xenitellis, can you give a hint, please?
    Simox Xenitellis, 힌트를 주실 수 있나요?

    1. I got you covered. It’s this post, https://blog.simos.info/configuring-public-ip-addresses-on-cloud-servers-for-lxd-containers/
      나는 너를 도와줄게. 이 게시물이다, https://blog.simos.info/configuring-public-ip-addresses-on-cloud-servers-for-lxd-containers/

  37. Thank you so much, this worked perfectly, with a minimum of hassles. I now have a lxd container running with a lan ip, statically assigned from my router. Now to configure it for server duties!
    정말 감사합니다. 이게 완벽하게 작동했어요, 최소한의 번거로움으로. 이제 라우터에서 정적으로 할당된 LAN IP를 가진 lxd 컨테이너가 실행되고 있습니다. 이제 서버 작업을 위해 구성해야겠어요!

    1. Thanks for your kind words! Glad it worked!
      친절한 말씀 감사합니다! 잘 되어서 기쁩니다!

  38. Actually famous last words 🙂
    사실 유명한 마지막 말 🙂

    Oddly, I can’t ping or ssh onto the container from the host, though I can from other PC’s
    이상하게도, 다른 PC에서는 할 수 있지만 호스트에서 컨테이너에 핑이나 SSH를 할 수 없습니다

    I presume this could be some routing issue? have rebooted the host to be sure.
    이것이 어떤 라우팅 문제일 수 있다고 생각합니다. 호스트를 재부팅하여 확인했습니다.

    1. The macvlan networking has this feature that there is no network communication between the host and any of the macvlan containers.
      macvlan 네트워킹은 호스트와 macvlan 컨테이너 간에 네트워크 통신이 없다는 기능을 가지고 있습니다.

      There is a valid explanation for this, and it is a known feature. Actually, you would choose macvlan partly because you can isolate the host from the LXD macvlan containers. This is really cool in terms of security; if a container gets somehow compromised, the host is insulated in terms of networking. Some more background reading: https://sreeninet.wordpress.com/2016/05/29/macvlan-and-ipvlan/
      이것에 대한 유효한 설명이 있으며, 이는 알려진 기능입니다. 실제로, 당신은 macvlan 를 선택할 것입니다. 부분적으로는 LXD macvlan 컨테이너로부터 호스트를 격리할 수 있기 때문입니다. 이는 보안 측면에서 정말 멋집니다. 만약 컨테이너가 어떤 식으로든 침해당하더라도, 호스트는 네트워킹 측면에서 차단됩니다. 추가 배경 읽기: https://sreeninet.wordpress.com/2016/05/29/macvlan-and-ipvlan/

      LXD supports several more ways to have a container get an IP address from the LAN. If you want the containers to communicate with the host, see the bridged post at https://blog.simos.info/how-to-make-your-lxd-containers-get-ip-addresses-from-your-lan-using-a-bridge/
      LXD는 컨테이너가 LAN에서 IP 주소를 얻는 여러 가지 방법을 지원합니다. 컨테이너가 호스트와 통신하도록 하려면 https://blog.simos.info/how-to-make-your-lxd-containers-get-ip-addresses-from-your-lan-using-a-bridge/의 브리지 게시물을 참조하세요.

      The slight difficulty in using a public bridge, is that you have to setup such a bridge on the host.
      공공 다리를 사용하는 데 약간의 어려움은 호스트에 그러한 다리를 설정해야 한다는 것입니다.

  39. Sorry for the spam, resolved the issue. Obviously can’t connect to host with macvlan. Tried routed but couldn’t get it to work – got the ip, but the container couldn’t talk to anything.
    스팸에 대해 사과드립니다, 문제를 해결했습니다. 분명히 macvlan으로 호스트에 연결할 수 없습니다. 라우팅을 시도했지만 작동하지 않았습니다 - IP는 얻었지만 컨테이너가 아무것과도 통신할 수 없었습니다.

    Got bridged to work, quite straightforward in the end.
    작업에 연결되었고, 결국 꽤 간단했습니다.

    Thanks for all the great tutorials!
    모든 훌륭한 튜토리얼에 감사드립니다!

  1. […] How to make your LXD containers get IP addresses from your LAN using macvlan […]

  2. […] of using a bridge, I will try to expose the containers directly on the LAN with macvlan. This guide is helpful. I change the default profile to use […]

  3. […] and the networking. The default LXD profile is suitable for this. You may use a bridge profile or macvlan profile […]

  4. […] post I used for setting up macvlan for the containers linked to this post, which explains how to have […]

  5. […] that, and HUGE thanks to this concise post by Simos Xenitellis, we can now configure a new profile with Macvlan for VMs that need a public IP. Simos’ post […]

  6. […] can also expose the Kali container on the network using either a bridge or macvlan, and it is as if it was a separate and independent […]

Leave a Reply  댓글 남기기

This site uses Akismet to reduce spam. Learn how your comment data is processed.
이 사이트는 스팸을 줄이기 위해 Akismet을 사용합니다. 귀하의 댓글 데이터가 어떻게 처리되는지 알아보세요.