Reserve IP address for out of bounds machines

aleskxyz commented 3 years ago

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

DaanHoogland commented 3 years ago

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 commented 3 years ago

@DaanHoogland I think this diagram can help:

DaanHoogland commented 3 years ago

like i described as the simple change ;)

aleskxyz commented 3 years ago

like i described as the simple change ;)

@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 commented 3 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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

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.

weizhouapache commented 2 years ago

@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

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.

@DaanHoogland in @aleskxyz 's diagram, the physical server uses a private IP in same range as guest VMs. from my understanding, the private IP needs to be reserved and not assigned to any VM. moreover, the private IP can be used as destination of static nat, port forwarding and LB. This is totally a different feature as #4357

aleskxyz commented 2 years ago

@DaanHoogland @weizhouapache is right. The goal of this request is to use network services for servers outside of CS but in the same subnet of the other vms in CS. because we want the VR to be GW for that server. Regarding to the IP reservation feature, yes it is a different request but I raise it to notice that we can design ip reservation feature a way that we could extend it later to meet out requirements on this request.

weizhouapache commented 2 years ago

@DaanHoogland @weizhouapache is right. The goal of this request is to use network services for servers outside of CS but in the same subnet of the other vms in CS. because we want the VR to be GW for that server. Regarding to the IP reservation feature, yes it is a different request but I raise it to notice that we can design ip reservation feature a way that we could extend it later to meet out requirements on this request.

@aleskxyz thanks for your confirmation.

CloudStack saves all public IPs in its database (user_ip_address table), so it is easier to reserve a public IP, for example set IP state to 'Reserved'. However it does not have a table for private Ips (private_ip_address table saves the info of private gateway). so it is more complex than public IP reservation.

a workaround for feature question is, (1) create a dummy vm with the private IP. do not start it. (2) stop the vm if you have started it. (3) create network rules to the vm/ip. by this way, the ip is allocated to a stopped vm but not actually in use.

aleskxyz commented 2 years ago

@DaanHoogland @weizhouapache is right. The goal of this request is to use network services for servers outside of CS but in the same subnet of the other vms in CS. because we want the VR to be GW for that server. Regarding to the IP reservation feature, yes it is a different request but I raise it to notice that we can design ip reservation feature a way that we could extend it later to meet out requirements on this request.

@aleskxyz thanks for your confirmation.

CloudStack saves all public IPs in its database (user_ip_address table), so it is easier to reserve a public IP, for example set IP state to 'Reserved'. However it does not have a table for private Ips (private_ip_address table saves the info of private gateway). so it is more complex than public IP reservation.

a workaround for feature question is, (1) create a dummy vm with the private IP. do not start it. (2) stop the vm if you have started it. (3) create network rules to the vm/ip. by this way, the ip is allocated to a stopped vm but not actually in use.

@weizhouapache You're welcome! It is a clever idea! But AFAIK there are some situations where VR checks power state of VM to change its configuration. We should take care of that.

weizhouapache commented 2 years ago

@aleskxyz indeed. In some cases, VR do not have dhcp/dns/userdata configuration for stopped vms. But it always has network rules for static nat, firewall rules and load balancer. it might not be a problem for you.

DaanHoogland commented 2 years ago

ok @weizhouapache @aleskxyz , so this is not about the configuration of the static nat/Portforwarding/LB at all? In that case it could be in a network detail. This 'feature' has been requested before.

weizhouapache commented 2 years ago

ok @weizhouapache @aleskxyz , so this is not about the configuration of the static nat/Portforwarding/LB at all? In that case it could be in a network detail. This 'feature' has been requested before.

@DaanHoogland this is not related to network details. the feature requests (1) reserve a private IP. do not allocate to any vms. (2) create static nat/port forwarding/load balancer to a reserved private IP.

not sure if it was requested by other users before. again, this feature looks simple, but it is actually not. It requires new db table, new APIs and some service layer changes.

in my opinion, this is not a common case. there is a workaround for it (see comments above). I suggest to move this out of 4.17.0.0 . @nvazquez

DaanHoogland commented 2 years ago

ok @weizhouapache @aleskxyz , so this is not about the configuration of the static nat/Portforwarding/LB at all? In that case it could be in a network detail. This 'feature' has been requested before.

@DaanHoogland this is not related to network details. the feature requests (1) reserve a private IP. do not allocate to any vms. (2) create static nat/port forwarding/load balancer to a reserved private IP.

not sure if it was requested by other users before. again, this feature looks simple, but it is actually not. It requires new db table, new APIs and some service layer changes.

in my opinion, this is not a common case. there is a workaround for it (see comments above). I suggest to move this out of 4.17.0.0 . @nvazquez

I agree taking it out of 4.17 for now. Having a private ip bridged out of cloudstack is not a new user case and the work around you mention works very well. I think we can implement this by creating a network detail to store the required private ips to reserve. No new table is needed, afaics. Whit is needed is the logic to take these values of the detail into account when signing need NICs in the network.

weizhouapache commented 2 years ago

ok @weizhouapache @aleskxyz , so this is not about the configuration of the static nat/Portforwarding/LB at all? In that case it could be in a network detail. This 'feature' has been requested before.

@DaanHoogland this is not related to network details. the feature requests (1) reserve a private IP. do not allocate to any vms. (2) create static nat/port forwarding/load balancer to a reserved private IP. not sure if it was requested by other users before. again, this feature looks simple, but it is actually not. It requires new db table, new APIs and some service layer changes. in my opinion, this is not a common case. there is a workaround for it (see comments above). I suggest to move this out of 4.17.0.0 . @nvazquez

I agree taking it out of 4.17 for now. Having a private ip bridged out of cloudstack is not a new user case and the work around you mention works very well. I think we can implement this by creating a network detail to store the required private ips to reserve. No new table is needed, afaics. Whit is needed is the logic to take these values of the detail into account when signing need NICs in the network.

@DaanHoogland BUT there is no api to create/update/remove network details

more complicated thing is, virtual machine id is a required parameter when enable static nat, create port forwarding rules. but the reserved IP does not belong to any virtual machine.