OpenStackをデプロイするためのテストベッドとしてマルチVMの迷惑な環境を使用しようとしていますが、1つのVMからVMの内部のVMに通信しようとすると、ネットワークの問題が発生しました。
2つのVagrantノード、クラウドコントローラーノードと計算ノードがあります。ホストオンリーネットワークを使用しています。私のVagrantfileは次のようになります:
Vagrant::Config.run do |config|
config.vm.box = "precise64"
config.vm.define :controller do |controller_config|
controller_config.vm.network :hostonly, "192.168.206.130" # eth1
controller_config.vm.network :hostonly, "192.168.100.130" # eth2
controller_config.vm.Host_name = "controller"
end
config.vm.define :compute1 do |compute1_config|
compute1_config.vm.network :hostonly, "192.168.206.131" # eth1
compute1_config.vm.network :hostonly, "192.168.100.131" # eth2
compute1_config.vm.Host_name = "compute1"
compute1_config.vm.customize ["modifyvm", :id, "--memory", 1024]
end
end
(QEMUベースの)VMを起動しようとすると、compute1で正常に起動し、その仮想NIC(vnet0)がブリッジbr100を介して接続されています。
root@compute1:~# brctl show 100
bridge name bridge id STP enabled interfaces
br100 8000.08002798c6ef no eth2
vnet0
QEMU VMがコントローラーで実行されているDHCPサーバー(dnsmasq)に要求を出すと、コントローラーのsyslogの出力が原因で、コントローラーに要求が到達したことがわかります。
Aug 6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPDISCOVER(br100) fa:16:3e:07:98:11
Aug 6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPOFFER(br100) 192.168.100.2 fa:16:3e:07:98:11
ただし、DHCPOFFERがVM compute1で実行中)に戻ることはありません。Vagrant(Mac OS X)を実行するホストマシンのvboxnet3インターフェイスでtcpdumpを使用して要求を監視すると、リクエストと返信の両方を見る
$ Sudo tcpdump -i vboxnet3 -n port 67 or port 68
tcpdump: WARNING: vboxnet3: That device doesn't support promiscuous mode
(BIOCPROMISC: Operation not supported on socket)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vboxnet3, link-type EN10MB (Ethernet), capture size 65535 bytes
22:51:20.694040 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:20.694057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:20.696047 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311
22:51:23.700845 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:23.700876 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:23.701591 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311
22:51:26.705978 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:26.705995 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:26.706527 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311
しかし、コンピュートのeth2でtcpdumpを実行すると、要求だけが表示され、応答は表示されません。
root@compute1:~# tcpdump -i eth2 -n port 67 or port 68
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
02:51:20.240672 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
02:51:23.249758 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
02:51:26.258281 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
この時点で、行き詰まっています。 DHCP応答が計算ノードに届かない理由がわかりません。おそらくそれは、VirtualBox仮想スイッチ/ルーターの構成と関係があるのでしょうか?
両方のノードのeth2インターフェイスが無差別モードに設定されていることに注意してください。
問題は、Vagrantを介してインターフェイスを無差別モードに設定する必要があることです。ゲストオペレーティングシステム内で行うだけでは十分ではありません。
たとえば、2つのNICを追加し、最後に定義したNICがVMにブリッジされるものである場合、Vagrantfileには次のようなものが含まれている必要があります。
compute1_config.vm.customize ["modifyvm", :id, "--nicpromisc3", "allow-all"]