Make VNC port be the first available from a range
|Assignee:||Carlos Martín||% Done:|
|Category:||Core & System|
|Target version:||Release 4.4|
|Affected Versions:||OpenNebula 4.2|
Currently, the VNC port is allocated by using the instance ID.
Because the instance id is a running number, the generated port can span a very big range, making the exceptions on the firewall too wide.
Also, there is an hard limit of < 65535 total instances that can be allocated per OpenNebula installation.
One suggestion to fix this issue:
- Let admin define a range for the VNC port
- Allocate the first available port on the range
I refer VNC, but this should also apply to SPICE as well.
Bug #2045: wrap around the vnc port number
(cherry picked from commit 005aa35739ac1b2ebe8646fc21283e75b8b5f785)
#1 Updated by Ruben S. Montero over 6 years ago
Maybe I am wrong, but I think that this limits the number of VMs running on a given host to 65535 not to OpenNebula. The port an collide only in the host running the VM.
My concern here is what happen when we overflow the port range. Probably we need just to use something like:
port = 5900 + id mod 15000
This will let you easily :
1.- configure your firewall
2.- set vnc port in a deterministic way from VM_id (with out probing...)
3.- not to overflow the port
The corner case is that a running VM is running and 15000 VMs after a new VM is allocated to the same host.
What do you think?
#2 Updated by Ricardo Duarte over 6 years ago
I'm not sure that the current implementation prevents overflow, so after the 65553 it will try 65554.
But this is still a per-opennebula limit, because ports are related to VMID.
So, if an instance takes a VMID in OpenNebula, the VNC port will be lost forever.
As for your solution, if the environment is too dynamic and there are some long standing persistent instances, the corner case may not be so rare.
I would prefer a deterministic way that ensures no collisions , but understand it may be overkill to search for the free port.