in Openstack
Assigning Limited Set of Floating IPs with Your DevStack
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.
|
1 2 3 4 5 6 7 8 9 10 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 | - | 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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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 :).
