创建大卷实例遇RetryFilter运行、双IP及iSCSI连接失败求助

Let’s break down each of your problems with practical, actionable steps based on common OpenStack pitfalls:

1. Creating Cloud Volumes Larger Than 80GB #

If you’re blocked from spinning up large volumes, start with these targeted checks:

• Verify Quota Limits: Check your project’s volume quota (total capacity and per-volume size) via the dashboard or CLI: openstack quota show --project <your-project>. If limits are too low, request an increase from your cloud admin.
• Check Backend Storage Support: Confirm your underlying storage (e.g., Ceph, LVM) allows large volumes. For example, Ceph has no hard size caps, but LVM might require adjusting physical volume configurations if you hit partition limits.
• Validate Volume Type Constraints: Some performance-tier volume types (like premium SSDs) may have predefined max size limits. Use openstack volume type show <type-name> to confirm the specs.
• Double-Check Inputs: Make sure you’re using the right unit (GB vs TB) when creating the volume—typos here can lead to unexpected failures.

2. Slow Instance Boot with iSCSI Connection Warnings in nova-scheduler.log #

The Failed to connect to iSCSI portal warning is directly causing your slow boot time—OpenStack is retrying the connection repeatedly. Here’s how to fix it:

• Test Network Connectivity: From your compute node (where nova runs), ping the 10.x.x.x portal IP and verify port 3260 (default iSCSI port) is open using telnet 10.x.x.x 3260 or nc -zv 10.x.x.x 3260. Firewalls, security groups, or ACLs often block this port.
• Validate iSCSI Tooling: Ensure iscsiadm is installed and functional on the compute node. Run iscsiadm -m discovery -t st -p 10.x.x.x—if this fails, the iSCSI initiator configuration is broken; reinstall or reconfigure the service.
• Check Storage Node Health: On the storage node hosting the iSCSI target, confirm the target service (e.g., tgt or targetd) is running and error-free. Review logs for issues with target setup.
• Review Nova/os-brick Configs: Verify nova.conf has correct iSCSI settings, especially iscsi_helper (match your distro, e.g., iscsiadm for RHEL/Ubuntu) and CHAP auth parameters if your targets require it.

Fixing the iSCSI connection issue will immediately reduce your instance boot time.

3. Duplicate IP Addresses After RetryFilter Runs #

RetryFilter retries scheduling if the first attempt fails, but sometimes leaves orphaned IP allocations. Here’s how to resolve this:

• Check Neutron Port/IP State: Use openstack port list --server <instance-id> to see if two ports are attached to the instance. One is likely an orphan from the failed first scheduling attempt.
• Clean Up Orphaned Resources: Delete the unused port (verify which one isn’t active by checking status and fixed_ips fields) to release the duplicate IP.
• Adjust RetryFilter Settings: In nova.conf, tweak retry_interval and max_retries to reduce partial resource allocations before a retry. You can disable RetryFilter if it’s not critical for your environment, though this isn’t recommended for high availability setups.
• Validate Neutron’s IP Reclaim Logic: Ensure Neutron releases IPs from failed instances promptly. Check the port_timeout setting in neutron.conf—a shorter timeout can prevent orphaned IPs.

内容的提问来源于stack exchange，提问作者golfreeze