Проблемна мережа з декількома вузлами, що працює лише для хостів

Я намагаюсь використовувати багатовідовий бродячий середовище як тестовий майданчик для розгортання OpenStack, і я зіткнувся з мережевою проблемою, намагаючись зв’язатися з однієї VM, до VM всередині VM.

У мене є два бродячих вузла, вузол хмарного контролера та обчислювальний вузол. Я використовую лише мережеві мережі. Мій 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

Коли я намагаюся запустити VM на основі QEMU, він завантажується успішно на 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), що працює на контролері, я можу побачити, що запит доходить до контролера через вихід на системний журнал на контролері:

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, що працює на обчисленні1. Якщо я переглядаю запити, використовуючи tcpdump в інтерфейсі vboxnet3 на моїй хост-машині, на якій працює Vagrant (Mac OS X), я можу побачити і запити, і відповіді.

$ 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

Але, якщо я tcpdump на eth2 для обчислення, я бачу лише запити, а не відповіді:

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, але це робити всередині гостьових операційних систем недостатньо.

Наприклад, якщо ви додасте два NIC, і останній NIC, який ви визначите, це той, який буде з'єднаний з VM, ваш Vagrantfile повинен містити щось на зразок:

compute1_config.vm.customize ["modifyvm", :id, "--nicpromisc3", "allow-all"]