Problem sieci Vagrant (Virtualbox) tylko z wieloma hostami

Próbuję użyć błędnego środowiska wielu maszyn wirtualnych jako platformy testowej do wdrażania OpenStack i napotkałem problem z siecią podczas próby komunikacji z jedną maszyną wirtualną na maszynie wirtualnej wewnątrz maszyny wirtualnej.

Mam dwa węzły Vagrant, węzeł kontrolera chmury i węzeł obliczeniowy. Używam sieci tylko do hosta. Mój plik Vagrant wygląda następująco:

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

Kiedy próbuję uruchomić maszynę wirtualną (opartą na QEMU), uruchamia się ona pomyślnie na compute1, a jej wirtualna nic (vnet0) jest połączona mostem, br100:

root@compute1:~# brctl show 100
bridge name bridge id       STP enabled interfaces
br100       8000.08002798c6ef   no      eth2

                        vnet0

Gdy maszyna wirtualna QEMU wysyła żądanie do serwera DHCP (dnsmasq) działającego na kontrolerze, widzę, że żądanie dociera do kontrolera z powodu danych wyjściowych w dzienniku syslog na kontrolerze:

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 

Jednak DHCPOFFER nigdy nie wraca do maszyny wirtualnej działającej na compute1. Jeśli oglądam żądania za pomocą tcpdump na interfejsie vboxnet3 na moim hoście, na którym działa Vagrant (Mac OS X), widzę zarówno żądania, jak i odpowiedzi

$ 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

Ale jeśli uruchomię tcpdump na eth2 podczas obliczeń, widzę tylko żądania, a nie odpowiedzi:

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

W tym momencie utknąłem. Nie jestem pewien, dlaczego odpowiedzi DHCP nie docierają do węzła obliczeniowego. Być może ma to coś wspólnego z konfiguracją wirtualnego przełącznika / routera VirtualBox?

Zauważ, że interfejsy eth2 w obu węzłach zostały ustawione na tryb rozwiązły.

Problem polega na tym, że interfejs Vagrant musi być ustawiony w tryb rozwiązawczy, nie wystarczy to zrobić w systemach operacyjnych gościa.

Na przykład, jeśli dodasz dwie karty sieciowe, a ostatnia karta sieciowa, którą zdefiniujesz, będzie połączona z maszynami wirtualnymi, plik Vagrantfile powinien zawierać coś takiego:

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