Bug #2045

Make VNC port be the first available from a range

Added by Ricardo Duarte almost 6 years ago. Updated over 5 years ago.

Status:ClosedStart date:05/14/2013
Priority:NormalDue date:
Assignee:Carlos Martín% Done:

0%

Category:Core & System
Target version:Release 4.4
Resolution:fixed Pull request:
Affected Versions:OpenNebula 4.2

Description

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.

Associated revisions

Revision 005aa357
Added by Carlos Martín over 5 years ago

Bug #2045: wrap around the vnc port number

Revision 7d128316
Added by Carlos Martín over 5 years ago

Bug #2045: wrap around the vnc port number
(cherry picked from commit 005aa35739ac1b2ebe8646fc21283e75b8b5f785)

Revision f87db8f3
Added by Carlos Martín over 5 years ago

Bug #2045: wrap around the vnc port number

(cherry picked from commit 005aa35739ac1b2ebe8646fc21283e75b8b5f785)

History

#1 Updated by Ruben S. Montero almost 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 almost 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.

#3 Updated by Javi Fontan over 5 years ago

  • Tracker changed from Request to Bug

This is a bug as it prevents to have more IDs bigger that 65535-base_port with VNC ports open.

#4 Updated by Ruben S. Montero over 5 years ago

  • Category set to Core & System
  • Status changed from Pending to Closed
  • Assignee set to Carlos Martín
  • Target version set to Release 4.4
  • Resolution set to fixed
  • Affected Versions OpenNebula 4.2 added

Also available in: Atom PDF