Dag, Nitin:
Thanks very much for your help. With info from both of you, I am able to solved
the problem.
Based on Dag’s query, without clause “AND
cloud.op_dc_ip_address_alloc.reservation_id = cloud.nics.reservation_id)”, I
found a stale IP reservation belonging to the very first SSVM (which was long
gone!) after the site was first created almost three years ago:
+----+-------------+--------+--------+------------+--------+
| id | ip_address | pod_id | nic_id | network_id | name |
+----+-------------+--------+--------+------------+--------+
| 7 | 10.0.100.57 | 1 | 6 | 200 | s-2-VM |
+----+-------------+--------+--------+------------+--------+
So, I run following update statement to set all relevant columns to NULL:
mysql> update op_dc_ip_address_alloc set
nic_id=null,reservation_id=null,taken=null where id=7;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Once this is done, I am able to modify reserved IP ranges on Pod details page
via web GUI. Since this is my lab ACS environment and over last three years,
it went thru multiple upgrades, and was broken numerous times, I am not
surprised at all that there are some junks remaining in my DB!
Have good day!
Yiping
On 10/25/17, 2:00 AM, "Nitin Kumar Maharana"
<nitinkumar.mahar...@accelerite.com> wrote:
Hi Yiping,
As Dag said, the table(cloud.op_dc_ip_address_alloc) contains the detail of
each IP(including the reservation status etc..)
The field (reservation_id and taken) say, if the IP is allocated to anyone.
If both the values are not null then it is allocated.
Before shrinking we should make sure the IP is not allocated to
anyone(should be free).
Once we tried shrinking the range using DB hack in our dev environment. But
I won’t recommend it in a production environment.
Basically you have to reduce the value in (cloud.host_pod_ref) table. For
e.g, replace the range (10.102.193.170-10.102.193.209) to
(10.102.193.171-10.102.193.208), It’s just a string. Before doing that we
should make sure the shrinking IPs are not allocated to anyone.
Next, delete the IP entries from table(cloud.op_dc_ip_address_alloc).
According to the above e.g, we should delete the IP entries (10.102.193.170 &
10.102.193.209). (Note: Make sure the reservation_id and taken field is NULL
for both the IPs)
We have a pending PR(https://github.com/apache/cloudstack/pull/2048), which
allows a user to perform below operations.
- Add a mutually exclusive range.
- Delete a range if none of the IP is allocated.
- List down the range in GUI. (Home -> Infrastructure -> Zones ->
<your_zone> -> <your_physical_network> -> Management -> IP Ranges)
I recommend you to try with the above feature. Where you can flexibly add
and delete the range anytime.
Thanks,
Nitin
* Infrastructure
* Zones
* Nitin
* Physical Network 1
* Management
On 25-Oct-2017, at 2:01 PM, Dag Sonstebo
<dag.sonst...@shapeblue.com<mailto:dag.sonst...@shapeblue.com>> wrote:
Hi Yiping,
Which hypervisor do you use? Keep in mind if you use VMware then every VR
will also get an IP address in this same range – hence you need to have enough
IP addresses to cover all your networks, VPCs and SSVM+CPVM.
If you want to check in your DB the management IP range is defined in:
- host_pod_ref.description: think this is cosmetic
- cloud.op_dc_ip_address_alloc: row per IP address – and you have to
reference “nic” and “reservation_id” back to the “nics” table and from there
reference the “vm_instance” table.
Something like this should work – but double check it please – this was
just quickly thrown together:
SELECT
cloud.op_dc_ip_address_alloc.id,
cloud.op_dc_ip_address_alloc.ip_address,
cloud.op_dc_ip_address_alloc.pod_id,
cloud.op_dc_ip_address_alloc.nic_id,
cloud.nics.network_id,
cloud.vm_instance.name
FROM
cloud.op_dc_ip_address_alloc
LEFT JOIN
cloud.nics ON (cloud.op_dc_ip_address_alloc.nic_id = cloud.nics.id
AND cloud.op_dc_ip_address_alloc.reservation_id =
cloud.nics.reservation_id)
LEFT JOIN
cloud.vm_instance on (cloud.nics.instance_id = cloud.vm_instance.id)
WHERE
cloud.op_dc_ip_address_alloc.reservation_id IS NOT NULL;
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 25/10/2017, 01:28, "Yiping Zhang"
<yzh...@marketo.com<mailto:yzh...@marketo.com>> wrote:
Hi, all:
In ACS web GUI, on the Pod Details page, the fields “Start IP” and “End
IP” are editable. This IP range is reserved for systemVM’s (SSVM/CPVM). When
I built my ACS environments three years ago, I gave this a large range without
fully understanding what it is for. Now I am short of IPs on the management
network, I would like to reduce this reserved range so that I can use some
extra IP for other things, like more hypervisor hosts!
When I try to trim some IP off either end, I get an error message: “The
specified pod has allocated private IP addresses. So its IP address range can
be extended only”, even though I know for facts that my system VM’s are not
using any of the IP’s that I am trying to free up.
So, I did the obvious thing: disabled the zone, and deleted all the
SSVM and CPVM’s. I even restarted the management service. However, when I try
again to edit “Start IP” and/or “End IP” fields on the Pod details page, I
still get the same error message above, even though now I have zero system VM!
This does not seem to be correct to me.
I guess, at this point, my only solution is to do direct DB
modifications. Can someone please tell me which table contains this
information? If any of you have successfully modified pod start/end IP without
going direct DB hacks, please share your approaches.
Thanks
Yiping
dag.sonst...@shapeblue.com<mailto:dag.sonst...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is
the property of Accelerite, a Persistent Systems business. It is intended only
for the use of the individual or entity to which it is addressed. If you are
not the intended recipient, you are not authorized to read, retain, copy,
print, distribute or use this message. If you have received this communication
in error, please notify the sender and delete all copies of this message.
Accelerite, a Persistent Systems business does not accept any liability for
virus infected mails.
