Backlog #3784
IP(v6) alias(es) support
| Status: | Pending | Start date: | 04/30/2015 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | - |
Description
This feature has been discussed before but somehow never made it to a feature request: http://lists.opennebula.org/pipermail/users-opennebula.org/2014-January/026313.html. The idea is to have the possibility to add IP alias(es) to a TEMPLATE and / or a running VM. This way it's possible to (still) have all addresses / leases managed by OpenNebula. Normally a "true" IP alias would get a subnet mask of "/32" (IPv4) or "/128" (IPv6). If the IP alias inherits the properties from the VNET / AR this subnet mask will not be correct. Ideally there would be an option to override the properties of the VNET / AR. To make this IP alias(es) work when "IP address hijack prevention" is active (openvswitch) a new OpenFlow rule needs to be added for every IP alias added (related issue #3181). If an alias would be added to a running VM a driver should be executed on the host the VM is running on to add this OpenFlow rule. Context scripts could be enhanced to automatically add the IP alias(es) (ip (-6) addr add ip/subnetmask dev interface). If it would be possible to override the mac-address in an AR reservation this could also solve the (virtual) ip-address / MAC (VRRP / CARP) problem.
Related issues
History
#1
Updated by Ruben S. Montero about 6 years ago
- Tracker changed from Feature to Backlog
- Category set to Core & System
- Target version set to Release 5.0
After some discussions in the forum, we've come out with the following design
NIC = [ NETWORK="public" NAME="main" ] NIC = [ NETWORK="public" ALIAS="main" ]
Interface with ALIAS attribute will not be included in the deployment file for the hypervisor. But it would be included in context as an alias for the target NIC.
#2
Updated by Stefan Kooman over 5 years ago
This feature does not (completely) solve the "(virtual) ip-address / MAC (VRRP / CARP)" problem. As it is currently not possible to request more than 1 "LEASE" from OpenNebula in a given AR / VNET. A special IP could be introduced that has the ability to have > 1 LEASE (allow duplicates) and as such the VIP be used in more than 1 VM.
#3
Updated by Ruben S. Montero over 5 years ago
- Tracker changed from Backlog to Feature
#4
Updated by Ruben S. Montero over 5 years ago
- Tracker changed from Feature to Backlog
- Priority changed from Normal to High
- Target version deleted (
Release 5.0)
#5
Updated by Ruben S. Montero about 5 years ago
Stefan Kooman wrote:
This feature does not (completely) solve the "(virtual) ip-address / MAC (VRRP / CARP)" problem. As it is currently not possible to request more than 1 "LEASE" from OpenNebula in a given AR / VNET. A special IP could be introduced that has the ability to have > 1 LEASE (allow duplicates) and as such the VIP be used in more than 1 VM.
Stefan, looking back to this issue... I think this could be covered by the new Virtual Router component. Virtual router can be deployed in a HA configuration, with multiple VMs implementing the routing capabilities. The VR can request IP which are shared by all the VMs implementing the VR. IMHO this is very similar to VRRP and probably address this issue...
More here:
http://docs.opennebula.org/5.0/operation/network_management/vrouter.html
#6
Updated by Ruben S. Montero about 5 years ago
Ruben S. Montero wrote:
Stefan Kooman wrote:
This feature does not (completely) solve the "(virtual) ip-address / MAC (VRRP / CARP)" problem. As it is currently not possible to request more than 1 "LEASE" from OpenNebula in a given AR / VNET. A special IP could be introduced that has the ability to have > 1 LEASE (allow duplicates) and as such the VIP be used in more than 1 VM.
Stefan, looking back to this issue... I think this could be covered by the new Virtual Router component. Virtual router can be deployed in a HA configuration, with multiple VMs implementing the routing capabilities. The VR can request IP which are shared by all the VMs implementing the VR. IMHO this is very similar to VRRP and probably address this issue...
More here:
http://docs.opennebula.org/5.0/operation/network_management/vrouter.html
In fact I think we are configuribg vrrp of keepalived for this
#7
Updated by Ruben S. Montero almost 5 years ago
- Related to Bug #1927: VM Context does not fill the right values when a VM has two NICs in the same network added