web-dev-qa-db-ja.com

ホスト外のlxcvmアクセス

Debian 64ビットでは、次のようにlxcを構成しました。

ホストIP：このホストの172.16.0.25 vmゲスト：172.16.0.44

ホストでブリッジを実行しました

auto eth0 
iface eth0 inet manual
        up ifconfig eth0 0.0.0.0 up
        down ifconfig eth0 down

auto br0 
iface br0 inet static
        bridge_ports eth0
        bridge_fd       0
        address 172.16.0.25
        netmask 255.255.255.0
        gateway 172.16.0.52

ゲスト側では、次のように構成を変更しました

lxc.utsname = myGuest
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.hwaddr = 00:FF:12:34:56:78
lxc.network.ipv4 = 172.16.0.44/24

VM：ホスト（172.16.0.25）とゲスト（172.16.0.44）は相互にpingを実行できますが、同じネットワーク上の他の物理マシン（172.16.0.0）は相互にpingを実行できません。私のゲストに会いましょう。

ホストのIPしか見ることができない私のゲストからの同じ問題！

実際、VmWareWorkstationのブリッジネットワークと同じ動作をしたいと思います。ネットワーク上の「どこでも」見られるように、VmWareはどのようなルーティングを行いますか？

（ちなみに、私のホストはすでにESXサーバー上にありますが、このレベルでは関係ないと思います）

networkingdebianvmware-workstationbridgelxc
1
Stef

ホストはVMwareで仮想化され、仮想スイッチに接続されます。仮想スイッチは、VMware仮想化サーバーのMACアドレスよりも多くのMACアドレスが表示されることを期待していません（VMwareゲスト内のlxcではありません）。したがって、これは間違いなくレイヤー2の問題です。VMWare（少なくともVSwitch）は、ホストのMACアドレスとは異なるMACアドレスを持つパケットを受信して​​ドロップしました。したがって、ゲストはVswitchを経由してアクセスする必要があるため、ゲストがホストの外部に到達する方法はありません。

回避策は、Vswitchで異なるMACアドレスを有効にすることです。これは、Vswitchの設定を編集することによって実行されます（VMwareホスト、構成、ネットワークで、lxc-Hostが接続されているvswitchを選択し、プロパティ、編集、セキュリティ、MACアドレスの変更->承認）。

4
philippe