Problema di rete a più nodi Vagrant (Virtualbox) solo host


9

Sto cercando di utilizzare un ambiente vagabondo multi-VM come banco di prova per la distribuzione di OpenStack e ho riscontrato un problema di rete con il tentativo di comunicare da una VM a una VM all'interno di una VM.

Ho due nodi Vagrant, un nodo controller cloud e un nodo di calcolo. Sto usando la rete solo host. Il mio Vagrantfile è simile al seguente:

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

Quando provo ad avviare una VM (basata su QEMU), si avvia correttamente su compute1 e la sua nic virtuale (vnet0) è connessa tramite un bridge, br100:

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

                        vnet0

Quando la VM QEMU effettua una richiesta al server DHCP (dnsmasq) in esecuzione sul controller, posso vedere che la richiesta raggiunge il controller a causa dell'output sul syslog sul controller:

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 

Tuttavia, DHCPOFFER non ritorna mai alla VM in esecuzione su compute1. Se guardo le richieste utilizzando tcpdump sull'interfaccia vboxnet3 sul mio computer host che esegue Vagrant (Mac OS X), posso vedere sia le richieste che le risposte

$ 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

Ma, se tcpdump su eth2 al momento del calcolo, vedo solo le richieste, non le risposte:

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

A questo punto, sono bloccato. Non sono sicuro del motivo per cui le risposte DHCP non arrivano al nodo di calcolo. Forse ha qualcosa a che fare con la configurazione dello switch / router virtuale VirtualBox?

Si noti che le interfacce eth2 su entrambi i nodi sono state impostate in modalità promiscua.

Risposte:


11

Il problema è che l'interfaccia deve essere impostata in modalità promiscua tramite Vagrant, non è sufficiente farlo all'interno dei sistemi operativi guest.

Ad esempio, se aggiungi due NIC e l'ultima NIC che definisci è quella che verrà collegata ai VM, il tuo Vagrantfile dovrebbe contenere qualcosa come:

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

3
puoi chiarire cosa specifica "nicpromisc3"?
jayunit100,

2
@ jayunit100 Imposta il terzo nic (che corrisponde a eth2) su "modalità promiscua", il che significa che VirtualBox invierà i pacchetti alla VM anche se l'indirizzo MAC dell'host di destinazione nel pacchetto non corrisponde all'indirizzo MAC del VM.
Lorin Hochstein,

1
Quindi --nicpromisc3 ​​è Adapter 3? Pertanto --nicpromisc2 è Adapter 2?
CMCDragonkai,

@CMCDragonkai Sì, ci credo.
Lorin Hochstein,

1
@Alfred vedi questa domanda per come correggere l' The following settings shouldn't exist: customizeerrore.
Nick Craig-Wood,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.