Repository navigation
Reserve IP address for out of bounds machines #4542
Description
Ability to define IP address beside of choosing VMs in Static NAT, Port Forward and Load balancer services to provide those services to servers outside of CloudStack.
ISSUE TYPE
- Feature Idea
COMPONENT NAME
VR
CLOUDSTACK VERSION
All versions
CONFIGURATION
Advanced networking
OS / ENVIRONMENT
N/A
SUMMARY
In some network services we need to specify which VM should use it. For example Static NAT, Port Forward and Load balancer.
It would be a good idea if we can also specify IP address of a server which is not managed by CloudStack.
This feature helps us to use network services provided by virtual router for physical servers or even VMs outside of CloudStack management area but share a common L2 network with other VMs in CloudStack.
This feature also requires reserve IP address capability in all type of networks. We can expand the issue #4357 for private IPs in isolated networks too.
STEPS TO REPRODUCE
1. Create an isolated network
2. In Port forward section define a new rule
3. In "Add VM" panel write IP address of the server outside of CloudStack
EXPECTED RESULTS
An iptables rule created in virtual router to forward desired port to the server IP
ACTUAL RESULTS
It is not possible to mention IP address of the server outside of CloudStack
Activity
DaanHoogland commentedon Dec 14, 2020
sounds good, but with lots of buts. are you going to invest in tech design @aleskxyz ?
I think I am reversing direction as opposed to what you are proposing but assigning loadbalancer configuration to an out of band (virtual) machine, would require an API served by that machine that cloudstack can use to add/remove hosts for a service.
If indeed you mean the other way around, it sounds like a simple change given #4357 .
aleskxyz commentedon Dec 14, 2020
@DaanHoogland
I think this diagram can help:
DaanHoogland commentedon Dec 14, 2020
like i described as the simple change ;)
aleskxyz commentedon Dec 14, 2020
@DaanHoogland 👍
As I told before this feature is dependent to #4357
User must reserve the IP before using it in Static NAT, Port Forward and Load balancer. Otherwise he/she should get an error message.
What do you mean about "tech design"?
If you mean writing "Design Document" in https://cwiki.apache.org/confluence/display/CLOUDSTACK/ , I can help.
DaanHoogland commentedon Dec 15, 2020
tnx @aleskxyz If you are not going to implement this it is sufficent to just be very precise here and find consent on it. With our discussion here it seems well scoped.
weizhouapache commentedon Feb 16, 2022
@aleskxyz
this looks different from #4357 which requested to reserve public IP.
this means to reserve private IPs in isolated networks/vpc tiers.
cc @nvazquez
DaanHoogland commentedon Feb 16, 2022
I don't think necessarily private, but as part of the range of IPs serving on the networkside, which would include the guestIPs, but also in this case an outside IP. Correct me If I'm wrong, but the Physical server having an IP inside the guest network in @aleskxyz ' picture seems irrelevant. It might as well be a google address.
33 remaining items
wido commentedon Feb 11, 2025
It all depends on what we put in the HAProxy config on the Virtual Router. It could technically point to an outside address.
DaanHoogland commentedon Oct 17, 2025
@aleskxyz , are you still interested in this or can we close?
github-actions commentedon May 6, 2026
This issue is stale because it has been open for 120 days with no activity. It may be removed by administrators of this project at any time. Remove the stale label or comment to request for removal of it to prevent this.
Jayd603 commentedon Aug 23, 2026
I ran into this issue - I installed a physical machine on a VPC VLAN off the (physical) network switch - manually assigned an IP within the VPC - works great. However, we need to A) be able to reserve the private VPC IP of the machine so that it does not conflict with other cloudstack actions and B) allow it to be used in port forwarding/LB rules etc.
Seems like a great feature that I'm surprised hasn't made it in yet. I am not sure it requires major re-engineering here. Just ability to add the IP as an external host and allow a feature or two (port forward,lb) to manage it within the UI/API.