On Wed, Sep 8, 2021, at 2:37 PM, os-user157 wrote:
Hi all,
I'm trying to deploy DevStack inside an Ubuntu Server 20.04.3 LTS virtual machine inside VirtualBox, but I'm struggling a lot, I got a lot of different errors.
My use case: I want to test Zuul and DevStack, so I'll create a virtual machine for DevStack and one for Zuul, both on VirtualBox. I'm using a Host-only adapter with CIDR 192.168.200.0/24, and I need DevStack to be accessible on this network, and to use this network as the floating range for giving floating IP addresses to instances inside DevStack, so that Zuul can also access them.
My local.conf: https://paste.openstack.org/show/809182/ Screenshots of the network configuration of my VirtualBox VM: First adapter, NAT (used for internet connectivity): https://i.imgur.com/C7XTiLJ.png Second adapter, host-only, used for communication with my Windows host and other VMs in the same network: https://i.imgur.com/Qeciuqx.png
DevStack is erroring with the arping command on lib/neutron-legacy, arping gets 0 responses and exits the script with exit code 1
Does anyone have experience in dpeloying DevStack inside VirtualBox in such manner? I really need some help with this, if anyone could give me some ideas of waht could be wrong, it'd very much appreciated! Thanks.
I've not done this before, but the multinode devstack + tempest CI jobs do something similar. In those jobs we create a layer2 network using vxlan between the instances then set up layer three such that 172.24.4.0/24 is used for the openstack services and 172.24.5.0/24 is used as the floating IP range. Then we have routes set up for 172.24.4.0/23 as on link connections allowing both /24 ranges to be routed properly. The disjoint sets are important here and I notice that you are overlapping your service/infrastructure IPs and the floating IP range. The first thing I would do is change that. Maybe use 192.168.200.128/25 as the floating IP range and then avoid that for the services. Also when you get errors from devstack it helps tremendously if you can share pastes of them so that others can see context and maybe understand why things broke. Another thing to note: running instances without nested virt is slow and may not produce a great Zuul test environment. When using nested virt we have noticed random crashes are relatively common. Something to be aware of. Are you trying to set this up for Zuul and Nodepool development? If so the Zuul and Nodepool test suites are actually pretty good at mocking out the cloud interactions and then upstream CI does do final verification against a devstack cloud. All that to say it might be easier to just rely on the test suite. Hope this helps, Clark