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.