Skip to main content

Overview

This guide covers platform-level load balancer issues requiring administrator access — service agent failures, appliance provisioning problems, and capacity-related performance degradation.
Administrator Access Required — This operation requires the admin role. Contact your Xloud administrator if you do not have sufficient permissions.
For user-facing issues (PENDING_CREATE status, member OFFLINE, TLS errors), see the Load Balancer User Troubleshooting guide.

Service Not Responding

Load balancer API service unavailable

Cause: The load balancer API service or worker containers may be stopped.Diagnose:
Check all load balancer service containers
docker ps --filter name=octavia
Check container logs for errors:
View API container logs
docker logs octavia_api --tail 100
View worker/health manager logs
docker logs octavia_worker --tail 100
docker logs octavia_health_manager --tail 100
Resolution: Restart services via XDeploy:
Restart load balancer services
xavs-ansible deploy --tags octavia
Cause: The load balancer worker cannot connect to the message queue, preventing it from receiving provisioning commands.Diagnose:
Check RabbitMQ connectivity from worker
docker exec octavia_worker python3 -c "
import pika
conn = pika.BlockingConnection(pika.URLParameters('amqp://octavia:<password>@<host>:5672/'))
print('RabbitMQ connection OK')
conn.close()
"
Resolution: Verify RabbitMQ is running and the octavia user credentials are correct.

Appliance Provisioning Failures

Cause: The management network DHCP pool has no available IP addresses.Diagnose:
Check DHCP pool usage
openstack subnet show lb-management-subnet \
  -c allocation_pools -c dns_nameservers
Count current appliance IPs in use
openstack loadbalancer amphora list \
  -c lb_network_ip | grep -v None | wc -l
Resolution: Expand the DHCP pool by updating the management subnet allocation range:
Update DHCP pool range
openstack subnet set \
  --allocation-pool start=<new-start>,end=<new-end> \
  lb-management-subnet
Cause: The appliance image is not registered in the Image Service, or it has been deactivated.Diagnose:
Check appliance image availability
openstack image list --tag amphora
Resolution: If the image is missing, re-upload it:
Upload amphora image
openstack image create \
  --disk-format qcow2 \
  --container-format bare \
  --file amphora-x64-haproxy.qcow2 \
  --tag amphora \
  --public \
  amphora-image

Performance Degradation

Cause: Appliance compute resources are saturated, or the backend member count has grown beyond the flavor profile’s rated capacity.Diagnose: Check appliance statistics for connection counts:
Check load balancer connection statistics
openstack loadbalancer stats show <lb-name>
Compare active_connections against the flavor profile’s rated capacity.Resolution: Create a new load balancer with a higher-capacity flavor and migrate listeners:
Flavor profiles cannot be changed on existing load balancers. To upgrade capacity:
  1. Create a new load balancer with the target flavor
  2. Recreate all listeners, pools, and members on the new load balancer
  3. Update DNS / floating IP to point to the new load balancer
  4. Delete the original load balancer after traffic is migrated

Service Log Reference

ContainerLog command
Load balancer APIdocker logs octavia_api --tail 100
Workerdocker logs octavia_worker --tail 100
Health managerdocker logs octavia_health_manager --tail 100
Housekeepingdocker logs octavia_housekeeping --tail 100

Next Steps

Monitoring

Set up proactive monitoring to catch issues before they impact production.

Flavor Profiles

Create higher-capacity flavor profiles for workloads experiencing saturation.

Architecture

Review the component relationships that can cause cascading failures.

Security

Verify management plane isolation after resolving connectivity issues.