Hi @joalmodo
So sorry for the documentation not being clear enough regarding this aspect. I’ll describe 2 common scenarios associated to floating IPs and how they can be implemented in OpenNebula.
Virtual IP (VIP)
So this scenario is common when implementing HA services where an IP is shared across several VMs. In this use case the VM IPs and the floating IP (the VIP) are part of the same network. Usually this is a private network as it requires 4 IPs to work.
So, for example the if the VIP is 10.0.0.1, you can float the IP across VM1, VM2, VM3 by simply attaching/detaching a NIC_ALIAS = [ NETWORK = “PrivateVNET”, IP = “10.0.0.1”] to the VM where you want to use the VIP
┌────┴───┐ ┌────┴───┐ ┌────┴───┐
│ │ │ │ │ │
│ VM-1 │ │ VM-2 │ │ VM-3 │
│ │ │ │ │ │
└──eth1──┘ └──eth1──┘ └──eth1──┘
│ │ │
10.0.0.2 10.0.0.3 10.0.0.4
│ │ │
│ │ │
───────┴────────────────────────────
Virtual Network 10.0.0.0/24 - VIP = 10.0.0.1
This requires that the VM’s respond to ARP/ND traffic for the VIP.
Shared Public IP
In this scenario you need some support from the routing backbone of your network to actually route the traffic to the VM that is assigned the IP to. Depending of your networking topology you may want to directly integrate this attach/detach process with your routing fabric.
For simple scenarios you can use the OpenNebula Virtual Router appliance (more info here) specifically the SDNAT4 module
The topology is as follows:
public Network (10.2.11.0/24)
┌─────────────────────────────────
┌──┴─┐
┌──┤eth0├──┐ eth0 IPs (10.2.11.1, 10.2.11.201. 10.2.11.202)
│ └────┘ │ 10.2.11.201 --> 172.20.0.128
│ Virtual │ 10.2.11.202 --> 172.20.0.130
│ Router │
│ ┌────┐ │
└──┤eth1├──┘
└─┬──┘ private network (172.20.0.0/24)
└────┬──────────────┬────────────┬────────────
172.20.0.128 172.20.0.67 172.20.0.130
┌──┴──┐ ┌──┴──┐ ┌──┴──┐
│ VM1 │ │ VM2 │ │ VM3 │
└─────┘ └─────┘ └─────┘
The procedure is the same, you simple attach/detach a NIC_ALIAS to float an IP from the public network, in this case the NIC ALIAS:
- Should be part of the Public Network (not the difference with the VIP scenario)
- Should include the EXTERNAL attribute, to let know VR to forward the traffic to the given VM
- The VM guest is not aware of this IP, like in AWS EC2 (also different form VIP use case)
In this case the VR will do the “routing” (actually NAT’ing) to send the floating IP traffic to the target VM. As mentioned above, you could replace the VR with a custom integration with your routing fabric leveraging the hooks (i.e. trigger some routing update whenever a NIC is attached/detached)
You have more information on how to use the Virtual Router appliance in the above link.
Cheers
Ruben