instance migration action shouldn't be allowed when there are existed VNC sessions

[Yaguang Tang]

instance migration action shouldn't be allowed when there are existed VNC sessions .
when doing a migration, all vnc tokens will become invalid from the source server. this breaks the existed VNC session.

[Michael H Wilson (geekinutah)]

I can reproduce this with a libvirt/kvm migration. The problem is that the vnc connection is handled by the qemu-kvm process. The migration takes care of migrating guest state but the vnc service is provided by the host. Since this is an admin initiated action I think we should probably fix this.

I guess you could, in the libvirt/kvm case, check and see if the process has an ESTABLISHED tcp connection. If there is one that is ESTABLISHED then we can die with an error like "There's someone using VNC". Note that this condition should be ignored in the evacuate case. We really aren't trying to be nice, we think hardware is going to fail or something so we want to move everyone off at emergency speed.

I know you can do this with ss in linux land, not sure about windows. More specifically, the tcp_diag module in the linux kernel is the one you need to ask. Alternatively you can consult /proc/net/tcp, but that is a quadratic lookup so use with care.

[Abhishek Kekane (abhishek-kekane)]

Possible Solution:
A new parameter "force" will be added to the existing live migration api, if it's set to False and user is connected to the VNC console, it won't live migrate that vm.

If "force" parameter is set to True then even if user is connected to VNC console, live migration will be performed.

To detect whether users are connected to the vnc console or not, we can check if the vnc port is opened on the compute node where the vm is running using following command.

sudo netstat -pnt | awk '{print $4}' | egrep '^127.0.0.1:5900$’
127.0.0.1 : vncserver_listen parameter from nova.conf
5900: graphics port either for spice or vnc.

[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