Hi Michael, thanks for taking the time reading this! The internal octavia network is a vlan on a physical network on the hosts. openstack --os-cloud admin subnet list --long gives: +--------------------------------------+----------------------------------------------------+--------+----------------------------------+-------+--------+--------------------------------------+--------------+-------------+--------------------+------+ | ID | Name | Status | Project | State | Shared | Subnets | Network Type | Router Type | Availability Zones | Tags | +--------------------------------------+----------------------------------------------------+--------+----------------------------------+-------+--------+--------------------------------------+--------------+-------------+--------------------+------+ ... | fe73f93f-9e76-4bd9-9ce4-e60882d313d9 | internal-octavia | ACTIVE | d52e2dccbc7e46d8b518120fa7c8753a | UP | False | fd10e49c-359a-45d0-b207-89ba3d438a68 | vlan | Internal | az-1, az-2 | | ... +--------------------------------------+----------------------------------------------------+--------+----------------------------------+-------+--------+--------------------------------------+--------------+-------------+--------------------+------+ so, Openstack seems to know the the network and it should work in both az. openstack --os-cloud admin subnet list --long gives: +--------------------------------------+---------------------------------------------------+--------------------------------------+--------------------+----------------------------------+-------+--------------+---------------------------------+-------------+------------+-----------------+---------------+------+ | ID | Name | Network | Subnet | Project | DHCP | Name Servers | Allocation Pools | Host Routes | IP Version | Gateway | Service Types | Tags | +--------------------------------------+---------------------------------------------------+--------------------------------------+--------------------+----------------------------------+-------+--------------+---------------------------------+-------------+------------+-----------------+---------------+------+ ... | fd10e49c-359a-45d0-b207-89ba3d438a68 | 172_20_48_0_20 | fe73f93f-9e76-4bd9-9ce4-e60882d313d9 | 172.20.48.0/20 | d52e2dccbc7e46d8b518120fa7c8753a | False | | 172.20.48.50-172.20.63.254 | | 4 | 172.20.48.1 | | | ... +--------------------------------------+---------------------------------------------------+--------------------------------------+--------------------+----------------------------------+-------+--------------+---------------------------------+-------------+------------+-----------------+---------------+------+ BTW, starting an instance manually in the service project with the correct network and the octavia image works. I recreated the availabilityzoneprofile via: openstack --os-cloud service_octavia loadbalancer availabilityzoneprofile create --name az-1 --provider amphora --availability-zone-data '{"compute_zone": "az-1", "management_network": "fe73f93f-9e76-4bd9-9ce4-e60882d313d9"}' openstack --os-cloud service_octavia loadbalancer availabilityzoneprofile create --name az-2 --provider amphora --availability-zone-data '{"compute_zone": "az-2", "management_network": "fe73f93f-9e76-4bd9-9ce4-e60882d313d9"}' but still no success. Am 2020-10-14 00:06, schrieb Michael Johnson:
Hi Björn,
Yeah, I don't see a reason in that nova log snippet, so I can 't point to the exact cause. It might be higher in the logs than the snippet included.
That said, it might be that the AZ definition in the AZ profile does not include the appropriate lb-mgmt-net ID for az-2. Without that defined, Octavia will use the default lb-mgmt-net ID from the configuration file, which is likely only available in az-1. I would try defining the management_network and valid_vip_networks for az-2.
Michael