Bug 33166 - noVNC connections not immediately possible after starting a VM
noVNC connections not immediately possible after starting a VM
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Virtualization - UVMM
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 3.2-0-errata
Assigned To: Erik Damrose
Philipp Hahn
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-06 18:25 CET by Erik Damrose
Modified: 2014-01-22 12:02 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
Immediately write noVNC token on domain state change (2.62 KB, patch)
2013-11-28 14:13 CET, Philipp Hahn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Damrose univentionstaff 2013-11-06 18:25:15 CET
It can take up to 15 seconds before one can connect to a just started instance. 

This is due to the fact that the /var/cache/univention-virtual-machine-manager-daemon/novnc.tokens file can only be updated with the connection information when uvmm has received it. Especially for Xen instances this can take up to 15 seconds. 

If the user clicks on the 'view' icon for the VM, she will receive a 'Failed to connect to server' message. 

To fix this the progress bar that is showing during VM bootup could be shown until a noVNC connection can be established.
Comment 1 Philipp Hahn univentionstaff 2013-11-28 14:13:47 CET
Created attachment 5681 [details]
Immediately write noVNC token on domain state change

The VNC port information is only available in the libvirt domain XML. This information is polled every update=15 seconds.

libvirt also provides an event mechanism, which (AFAIK) works reliable for KVM, but not for Xen (there was a problem was with Xend notifying libvirtd: starts/stop is detected, but not edit). It is already used by UVMMd to trigger Domain.update() when the VM changes state. It calls update_expensive() to get the XML, but that update is not passed up to Node.update() until the next regular update interval. Only there the VNC information is written into the token file.

Currently one mapping file is used for one host listing all running VMs of that host. Node.write_novnc_tokens() is run by the interval Node-thread, while the event is processed by a different Thread, so locking might be missing in the attached patch, which otherwise works find on my KVM test system.
Comment 2 Erik Damrose univentionstaff 2014-01-20 17:09:39 CET
The patch has been applied. Small modification: Use a tempfile with a unique name before moving it to the final filename to avoid multithreading issues.

On a Xen system the start and stop events are immediately processed and the token file is updated.

r47263 univention-virtual-machine-manager-daemon 3.0.17-2.481.201401201652
r47264 2014-01-20-univention-virtual-machine-manager-daemon.yaml
Comment 3 Philipp Hahn univentionstaff 2014-01-21 10:20:59 CET
OK: r47263
OK: r47264
OK: aptitude install {univention-virtual-machine-manager-daemon,univention-management-console-module-uvmm,python-univention-virtual-machine-manager}=3.0.17-2.481.201401201652
OK: announce_errata -V 2014-01-20-univention-virtual-machine-manager-daemon.yaml
OK: Works as expected on Qemu-KVM
Comment 4 Moritz Muehlenhoff univentionstaff 2014-01-22 12:02:25 CET
http://errata.univention.de/ucs/3.2/28.html