instance migration action shouldn't be allowed when there are existed VNC sessions
Bug #1240584 reported by
Yaguang Tang
This bug affects 4 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Expired
|
Undecided
|
Unassigned |
Bug Description
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.
Changed in nova: | |
assignee: | nobody → Yaguang Tang (heut2008) |
Changed in nova: | |
assignee: | Yaguang Tang (heut2008) → nobody |
tags: | added: console |
Changed in nova: | |
status: | New → Confirmed |
Changed in nova: | |
assignee: | nobody → Abhishek Kekane (abhishek-kekane) |
Changed in nova: | |
assignee: | Abhishek Kekane (abhishek-kekane) → nobody |
To post a comment you must log in.
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.