Sự cố mạng nhiều nút chỉ dành cho máy chủ Vagrant (Virtualbox)


9

Tôi đang cố gắng sử dụng một môi trường mơ hồ đa VM làm thử nghiệm để triển khai OpenStack và tôi đã gặp phải một vấn đề về mạng khi cố gắng giao tiếp từ một VM, với VM-bên trong VM.

Tôi có hai nút Vagrant, nút điều khiển đám mây và nút tính toán. Tôi đang sử dụng mạng chỉ lưu trữ. Vagrantfile của tôi trông như thế này:

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

Khi tôi cố gắng khởi động VM (dựa trên QEMU), nó khởi động thành công trên compute1 và nic ảo của nó (vnet0) được kết nối qua một cây cầu, br100:

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

                        vnet0

Khi QEMU VM thực hiện một yêu cầu đến máy chủ DHCP (dnsmasq) đang chạy trên bộ điều khiển, tôi có thể thấy yêu cầu đến bộ điều khiển do đầu ra trên syslog trên bộ điều khiển:

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 

Tuy nhiên, DHCPOFFER không bao giờ quay trở lại VM chạy trên compute1. Nếu tôi xem các yêu cầu bằng tcpdump trên giao diện vboxnet3 trên máy chủ chạy Vagrant (Mac OS X), tôi có thể thấy cả yêu cầu và phản hồi

$ 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

Nhưng, nếu tôi tcpdump trên eth2 trên máy tính, tôi chỉ thấy các yêu cầu, không phải trả lời:

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

Tại thời điểm này, tôi bị mắc kẹt. Tôi không chắc tại sao DHCP trả lời không làm cho nút tính toán. Có lẽ nó có liên quan đến cấu hình của bộ chuyển đổi / bộ định tuyến ảo VirtualBox?

Lưu ý rằng giao diện eth2 trên cả hai nút đã được đặt ở chế độ lăng nhăng.

Câu trả lời:


11

Vấn đề là giao diện phải được đặt ở chế độ lăng nhăng thông qua Vagrant, thực hiện nó bên trong các hệ điều hành khách là không đủ.

Ví dụ: nếu bạn thêm hai NIC và NIC cuối cùng mà bạn xác định là một NIC sẽ được bắc cầu tới VM, Vagrantfile của bạn sẽ chứa một cái gì đó như:

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

3
bạn có thể làm rõ những gì "nicpromisc3" chỉ định?
jayunit100

2
@ jayunit100 Nó đặt nic thứ ba (tương ứng với eth2) thành "chế độ lăng nhăng", có nghĩa là VirtualBox sẽ gửi các gói đến VM ngay cả khi địa chỉ MAC của máy chủ đích trong gói không khớp với địa chỉ MAC của VM.
Lorin Hochstein

1
Vậy --nicpromisc3 ​​là Adaptor 3? Do đó --nicpromisc2 là Adaptor 2?
CMCDragonkai

@CMCDragonkai Vâng, tôi tin là như vậy.
Lorin Hochstein

1
@Alfred xem câu hỏi này để biết cách sửa The following settings shouldn't exist: customizelỗi.
Nick Craig-Wood
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.