FAQ

コンテナー起動時の問題

もしコンテナーが起動しない場合や、期待通りの動きをしない場合に最初にすべきことは、コンテナーが生成したコンソールログを見ることです。 これには lxc console --show-log CONTAINERNAME コマンドを使います。

次の例では、systemd が起動しない RHEL 7 システムを調べています。

# lxc console --show-log systemd
Console log:

Failed to insert module 'autofs4'
Failed to insert module 'unix'
Failed to mount sysfs at /sys: Operation not permitted
Failed to mount proc at /proc: Operation not permitted
[!!!!!!] Failed to mount API filesystems, freezing.

ここでのエラーは、/sys と /proc がマウントできないというエラーです。これは非特権コンテナーでは正しい動きです。 しかし、LXD は 可能であれば 自動的にこれらのファイルシステムをマウントします。

コンテナーの要件 では、コンテナーには /sbin/init が存在するだけでなく、空の /dev/proc/sys フォルダーが存在していなければならないと定められています。 もしこれらのフォルダーが存在しなければ、LXD はこれらをマウントできません。そして、systemd がこれらをマウントしようとします。 非特権コンテナーでは、systemd はこれを行う権限はなく、フリーズしてしまいます。

何かが変更される前に環境を見ることはできます。raw.lxc 設定パラメーターを使って、明示的にコンテナー内の init を変更できます。 これは Linux カーネルコマンドラインに init=/bin/bash を設定するのと同じです。

lxc config set systemd raw.lxc 'lxc.init.cmd = /bin/bash'

次のようになります:

root@lxc-01:~# lxc config set systemd raw.lxc 'lxc.init.cmd = /bin/bash'
root@lxc-01:~# lxc start systemd
root@lxc-01:~# lxc console --show-log systemd

Console log:

[root@systemd /]#
root@lxc-01:~#

コンテナーが起動しましたので、コンテナー内で期待通りに動いていないことを確認できます。

root@lxc-01:~# lxc exec systemd bash
[root@systemd ~]# ls
[root@systemd ~]# mount
mount: failed to read mtab: No such file or directory
[root@systemd ~]# cd /
[root@systemd /]# ls /proc/
sys
[root@systemd /]# exit

LXD は自動修復を試みますので、起動時に作成されたフォルダもあります。コンテナーをシャットダウンして再起動すると問題は解決されます。 しかし問題の根源は依然として存在しています。テンプレートに必要なファイルが含まれていないという問題です

ネットワークの問題

大規模なプロダクション環境では、複数の VLAN を持ち、LXD クライアントを直接それらの VLAN に接続するのが一般的です。 netplan と systemd-networkd を使っている場合、いくつかの最悪の問題を引き起こす可能性があるバグに遭遇するでしょう。

VLAN ベースのブリッジでは netplan で systemd-networkd が使えない

執筆時点(2019-03-05)では、netplan は VLAN にアタッチされたブリッジにランダムな MAC アドレスを割り当てられません。 常に同じ MAC アドレスを選択するため、同じネットワークセグメントに複数のマシンが存在する場合、レイヤー 2 の問題が発生します。 複数のブリッジを作成することも困難です。代わりに network-manager を使ってください。 設定例は次のようになります。管理アドレスが 10.61.0.25 で、VLAN102 をクライアントのトラフィックに使います。

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    eth0:
      dhcp4: no
      accept-ra: no
      # This is the 'Management Address'
      addresses: [ 10.61.0.25/24 ]
      gateway4: 10.61.0.1
      nameservers:
        addresses: [ 1.1.1.1, 8.8.8.8 ]
    eth1:
      dhcp4: no
      accept-ra: no
      # A bogus IP address is required to ensure the link state is up
      addresses: [ 10.254.254.25/32 ]

  vlans:
    vlan102:
      accept-ra: no
      dhcp4: no
      id: 102
      link: eth1

  bridges:
    br102:
      accept-ra: no
      dhcp4: no
      interfaces: [ "vlan102" ]
      # A bogus IP address is required to ensure the link state is up
      addresses: [ 10.254.102.25/32 ]
      parameters:
        stp: false

注意事項

  • eth0 はデフォルトゲートウェイの指定がある管理インターフェースです
  • vlan102 は eth1 を使います
  • br102 は vlan102 を使います。そして bogus な /32 の IP アドレスが割り当てられています

他に重要なこととして、stp: false を設定することがあります。そうしなければ、ブリッジは最大で 10 秒間 learning 状態となります。これはほとんどの DHCP リクエストが投げられる期間よりも長いです。 クロスコネクトされてループを引き起こす可能性はありませんので、このように設定しても安全です。

'port security' に気をつける

スイッチは MAC アドレスの変更を許さず、不正な MAC アドレスのトラフィックをドロップするか、ポートを完全に無効にするものが多いです。 ホストから LXD インスタンスに ping できたとしても、異なった ホストから ping できない場合は、これが原因の可能性があります。 この原因を突き止める方法は、アップリンク(この場合は eth1)で tcpdump を実行することです。 すると、応答は送るが ACK を取得できない 'ARP Who has xx.xx.xx.xx tell yy.yy.yy.yy'、もしくは ICMP パケットが行き来しているものの、決して他のホストで受け取られないのが見えるでしょう。

不必要に特権コンテナーを実行しない

特権コンテナーはホスト全体に影響する処理を行うことができます。例えば、ネットワークカードをリセットするために、/sys 内のものを使えます。 これは ホスト全体 に対してリセットを行い、ネットワークの切断を引き起こします。 ほぼすべてのことが非特権コンテナーで実行できます。コンテナー内から NFS マウントしたいというような、通常とは異なる特権が必要なケースでは、バインドマウントを使う必要があるかもしれません。