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.
źródło
The following settings shouldn't exist: customize
błąd.