Recently, I wanted to use the public IPs assigned to my server to the devstack environment. The hosting company has allocated a /29 subnet for the server I am renting. In my local.conf I can either specify FLOATING_RANGE=204.xx.xxx.10/29 to so I can use 204.xx.xxx.10-14 as floating IPs for the VMs. However, I do not want to assign the first usable IP (204.xx.xxx.10) as the physical host is already using it so I can access the server remotely. If I do so otherwise, it will mess up the iptables rules on the server and lock me out.

There are two ways I can prevent the .10 IP to be associated as floating-IP, first, I can simply specify 204.xx.xxx.12/30 in the range so that nova will only use .13-.14 IPs but this kinda put the .11-.12 pair unused. So instead, I keep the /29 rage specified and I can manually associate floating IPs to my instances, skipping the .10. For example, using the nova client, it shows I have 6 usable IPs, when in fact I can only use the last 4.

revin@acme:~/devstack$ nova floating-ip-bulk-list
+------------+---------------+---------------+--------+-----------+
| project_id | address       | instance_uuid | pool   | interface |
+------------+---------------+---------------+--------+-----------+
| -          | 204.xx.xxx.9  | -             | public | br100     |
| -          | 204.xx.xxx.10 | -             | public | br100     |
| -          | 204.xx.xxx.11 | -             | public | br100     |
| -          | 204.xx.xxx.12 | -             | public | br100     |
| -          | 204.xx.xxx.13 | -             | public | br100     |
| -          | 204.xx.xxx.14 | -             | public | br100     |
+------------+---------------+---------------+--------+-----------+

To assign .11 IP manually, I can also use the nova-client this way and skip .9-.10:

revin@acme:~/devstack$ nova floating-ip-associate fedora 204.xx.xxx.11
revin@acme:~/devstack$ nova floating-ip-bulk-list
+------------+---------------+--------------------------------------+--------+-----------+
| project_id | address       | instance_uuid                        | pool   | interface |
+------------+---------------+--------------------------------------+--------+-----------+
| -          | 204.xx.xxx.9  | -                                    | public | br100     |
| -          | 204.xx.xxx.10 | -                                    | public | br100     |
| -          | 204.xx.xxx.11 | 654af53b-6acc-40f3-acf3-552598b4b651 | public | br100     |
| -          | 204.xx.xxx.12 | -                                    | public | br100     |
| -          | 204.xx.xxx.13 | -                                    | public | br100     |
| -          | 204.xx.xxx.14 | -                                    | public | br100     |
+------------+---------------+--------------------------------------+--------+-----------+
revin@acme:~/devstack$ nova list
+--------------------------------------+--------+--------+------------+-------------+-----------------------------------+
| ID                                   | Name   | Status | Task State | Power State | Networks                          |
+--------------------------------------+--------+--------+------------+-------------+-----------------------------------+
| 654af53b-6acc-40f3-acf3-552598b4b651 | fedora | ACTIVE | -          | Running     | private=10.11.12.2, 204.xx.xxx.13 |
+--------------------------------------+--------+--------+------------+-------------+-----------------------------------+

When using Horizon, avoid doing the association via Project > Compute > Instances > Associate Floating IP. This will pick the first available floating IP which is not what you want. Instead, do it via Project > Compute > Access & Security > Floating IPs, then allocate IPs to the project until you get the first IP you can assign.

I wish somehow Nova-Network can exclude some IPs from this range to make it easier :).