Problème de mise en réseau de plusieurs nœuds uniquement sur l'hôte Vagrant (Virtualbox)

9

J'essaie d'utiliser un environnement vagabond multi-VM comme banc d'essai pour déployer OpenStack, et j'ai rencontré un problème de réseau en essayant de communiquer à partir d'une VM vers une VM à l'intérieur d'une VM.

J'ai deux nœuds Vagrant, un nœud de contrôleur cloud et un nœud de calcul. J'utilise un réseau uniquement hôte. Mon Vagrantfile ressemble à ceci:

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

Lorsque j'essaie de démarrer une machine virtuelle (basée sur QEMU), elle démarre avec succès sur compute1, et son nic virtuel (vnet0) est connecté via un pont, br100:

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

                        vnet0

Lorsque la machine virtuelle QEMU fait une demande au serveur DHCP (dnsmasq) exécuté sur le contrôleur, je peux voir que la demande atteint le contrôleur en raison de la sortie sur le syslog sur le contrôleur:

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 

Cependant, le DHCPOFFER ne revient jamais sur la machine virtuelle exécutée sur compute1. Si je regarde les demandes à l'aide de tcpdump sur l'interface vboxnet3 sur ma machine hôte qui exécute Vagrant (Mac OS X), je peux voir à la fois les demandes et les réponses

$ 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

Mais, si je tcpdump sur eth2 sur compute, je ne vois que les requêtes, pas les réponses:

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

À ce stade, je suis coincé. Je ne sais pas pourquoi les réponses DHCP ne parviennent pas au nœud de calcul. Peut-être que cela a quelque chose à voir avec la configuration du commutateur / routeur virtuel VirtualBox?

Notez que les interfaces eth2 sur les deux nœuds ont été définies en mode promiscuous.

Lorin Hochstein
la source

Réponses:

11

Le problème est que l'interface doit être configurée en mode promiscuité via Vagrant, le faire à l'intérieur des systèmes d'exploitation invités n'est pas suffisant.

Par exemple, si vous ajoutez deux NIC et que le dernier NIC que vous définissez est celui qui sera ponté vers les VM, votre Vagrantfile devrait contenir quelque chose comme:

compute1_config.vm.customize ["modifyvm", :id, "--nicpromisc3", "allow-all"]
Lorin Hochstein
la source
3
pouvez-vous préciser ce que "nicpromisc3" spécifie?
jayunit100
2
@ jayunit100 Il définit le troisième nic (qui correspond à eth2) sur "mode promiscuous", ce qui signifie que VirtualBox enverra des paquets à la machine virtuelle même si l'adresse MAC de l'hôte de destination dans le paquet ne correspond pas à l'adresse MAC du VM.
Lorin Hochstein
1
Donc --nicpromisc3 ​​est l'adaptateur 3? Par conséquent, --nicpromisc2 est l'adaptateur 2?
CMCDragonkai
@CMCDragonkai Oui, je le crois.
Lorin Hochstein
1
@Alfred voir cette question pour savoir comment corriger l' The following settings shouldn't exist: customizeerreur.
Nick Craig-Wood du