OpenNebula

By default and for novnc to be able to connect the vnc server of libvirt from the frontend node, Opennebula passes 0.0.0.0 as a listen IP to libvirt. This can lead to conflicts with other processes on the hypervisor node (e.g. ceph client)

0.0.0.0 makes leads to libvirt trying to bind the VNC server on all interfaces of the host. In our case this at some point conflicts with outgoing connections of the ceph client, cause Opennebula by chance tries to bind to a port that Ceph uses for the connection to the OSD node. If Opennebula would not pass 0.0.0.0, but the IP of the interface that novnc will try to connect to, we would prevent the issue (at least if you use a dedicated interface for ceph connections, which is best practice)

Another solution would be to take a different approach in deciding on the VNC port for a VM. From a certain cluster size (or actually # of spawned Instances, we currently reached VMID 28000 or so) on, the approach of using the ID will anyways not work as expected. You could use a configurable range of ports that than could be reserved on the hosts systems. Given that the amount of machines one single host can handle is limited, one could define a range of like 10000 ports, and reserve it on the host machine, so that it is not used for e.g. outgoing connections of any kind. Still the binding on the interface that novnc will try to connect to makes sense, also from security perspective. Why should VNC be listening on the storage network

We use Opennebula 5.0.2 on Ubuntu 14.04 and 16.04 nodes with KVM and Ceph.