Is it possible to automatically reassign VNC ports when ports are already assigned

I wonder why I see many attempts to deploy a VM to several hosts (probably elected by the scheduler based on resource availability) when there is a VNC port already in use error.

As I understood from earlier discussions on this forum the VNC assignment is clusterwide. So why try to attempt to deploy to many hosts resulting in the same error without choosing a known free port. I would imagine that there is supposed to be a mechanism to assign a new (free) VNC port. And since Opennebula knows (or is assumed to know) what ports are used throughout the whole cluster it tries to assign used ports anyway and then stick to it for eternity as it seems. Is there something to configure to make it behave in a different manner?
It happens not only for “old” VM’s, but occasionally also for new VM’s.

Since it seems that the central database is not always in sync with what is used on the compute nodes, is there a mechanism to retrieve the current state of the cluster with respect to this (and maybe other resources) to be able to correct incorrect central knowledge?

I heard about the onedb fsck command, but that only seems to restore internal database consistency. This tool was used on several occassions, but does not seem to get an actual consistent view of the cluster.

Used onedb fsck with a modified fsck script (see other discussion on this forum) here.
This fixed long time pending machines because of this error. But today two machines were started after being shutdown for a few days, and they run into this problem, both wanting to use the same VNC port. Very annoying.


Agree. There are two issues here:

  • This is a bug, probably you are
    being hit by this one if you are undeploying the VMs. VNC ports are
    reserved for each VM in each cluster in order to avoid collisions. However
    currently when the VM is freeing the port it is not resetting it. If you
    are in 5.4 you can fix that with onedb change-body

  • This is to use autoport and
    probably get rid of this problems.


Hi Ruben,

Thank you for your valuable feedback. I will study the second link and the set of patches for 5.2.1. We currently have no plans to upgrade to 5.4 yet.
I will update this issue with the results. First we need to decide whether it is a valid and safe solution for our situation.