Vagrant (Virtualbox) Host-only-Netzwerkproblem mit mehreren Knoten

Ich versuche, eine Umgebung mit mehreren VMs als Testumgebung für die Bereitstellung von OpenStack zu verwenden, und ich habe ein Netzwerkproblem beim Versuch, von einer VM zu einer VM innerhalb einer VM zu kommunizieren.

Ich habe zwei Vagrant-Knoten, einen Cloud-Controller-Knoten und einen Rechenknoten. Ich verwende nur Host-Netzwerke. Mein Vagrantfile sieht so aus:

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

Wenn ich versuche, eine (QEMU-basierte) VM zu starten, startet sie erfolgreich auf compute1 und ihre virtuelle Netzwerkkarte (vnet0) ist über eine Bridge verbunden, br100:

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

                        vnet0

Wenn die QEMU-VM eine Anfrage an den auf dem Controller ausgeführten DHCP-Server (dnsmasq) sendet, kann ich sehen, dass die Anfrage den Controller aufgrund der Ausgabe im Syslog auf dem Controller erreicht:

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 

Der DHCPOFFER schafft es jedoch nie zurück zur VM, die auf compute1 ausgeführt wird. Wenn ich die Anforderungen mit tcpdump auf der vboxnet3-Schnittstelle meines Host-Computers beobachte, auf dem Vagrant (Mac OS X) ausgeführt wird, werden sowohl die Anforderungen als auch die Antworten angezeigt

$ 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

Aber wenn ich beim Rechnen auf eth2 tcpdumpe, sehe ich nur die Anfragen, nicht die Antworten:

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

An diesem Punkt stecke ich fest. Ich bin nicht sicher, warum die DHCP-Antworten es nicht zum Rechenknoten schaffen. Vielleicht hat es etwas mit der Konfiguration des virtuellen Switch / Routers von VirtualBox zu tun?

Beachten Sie, dass die eth2-Schnittstellen auf beiden Knoten auf den Promiscuous-Modus eingestellt wurden.

Das Problem ist, dass die Schnittstelle über Vagrant auf den Promiscuous-Modus eingestellt werden muss, was nicht ausreicht, um dies innerhalb der Gastbetriebssysteme zu tun.

Wenn Sie beispielsweise zwei Netzwerkkarten hinzufügen und die letzte von Ihnen definierte Netzwerkkarte diejenige ist, die mit den VMs verbunden wird, sollte Ihre Vagrant-Datei Folgendes enthalten:

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