VMware: find how to allocate unique VNC ports per host

[Radoslav Gerganov]

If VNC is enabled, we must allocate unique VNC ports for each created instance to avoid security issues with port collisions (see bug #1255609).

One way to guarantee uniqueness is to query vCenter for all allocated ports like this:

    vnc_port_prop = 'config.extraConfig["RemoteDisplay.vnc.port"]'
    result = session._call_method(vim_util, "get_objects",
                                  "VirtualMachine", [vnc_port_prop])

and then choose port number which is not in the result set.

The drawback of this approach is that it guarantees uniqueness across the whole vCenter whereas we need uniqueness only per ESX host. As a result the maximum number of VMs (with VNC enabled) that can be provisioned on vCenter would be 65535. Given that the maximum number of registered VMs in vCenter is 15000 (source: http://goo.gl/u90zhZ) this looks acceptable but it is still annoying limitation.

One solution I can think of, is to change the spawn() method to do something like this:
1. create VM
2. retrieve the ESX host on which the VM was created
3. create vim session to the ESX, run the query above and choose port number
4. reconfig the VM with the port number from step 3

I am not sure if creating sessions to ESX hosts is something that we want to do ...

[Sagar Ratnakara Nikam (sagar-r-nikam)]

Uniqueness should be at cluster level instead of host level , since DRS can migrate the VM to another host and it can result in 2 instances having the same port.

[kylin chou (shuaizi614)]

as i know, instance of vmware hypervisor supports migration, while migrating to another vmware cluster, does nova-compute reconfig the vnc port ?

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY