mirror of
https://github.com/retspen/webvirtmgr.git
synced 2026-04-26 08:05:54 +03:00
[GH-ISSUE #595] Probable console bug #450
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @majales on GitHub (Jan 18, 2016).
Original GitHub issue: https://github.com/retspen/webvirtmgr/issues/595
I've probably found console bug. I try to document bug by 3 examples of configuration. I all cases this is configuration of Webvirtmgr running on separate webserver, connecting to remote virtualization machines through TCP socket with auth. All my machines are running Debian Wheezy, Qemu is installed from debian-backports.
Servers configuration is following:
webserver:
IP: 192.168.0.10
FQDN: webvirtmgr.company.tld
Webvirtmgr settings in /var/www/webvirtmgr/webvirtmgr/settings.py:
SECRET_KEY = None
LOCAL_PATH = None
TIME_JS_REFRESH = 2000
WS_PORT = '6080'
WS_HOST = 'webvirtmgr.company.tld'
WS_PUBLIC_HOST = 'webvirtmgr.company.tld'
WS_CERT = None
virualization machine 1:
IP: 192.168.0.100
FQDN: virt1.company.tld
virualization machine 1:
IP: 192.168.0.200
FQDN: virt2.company.tld
Connecting to webserver nginx listening on port 8080 with following config:
server { listen 8080 default_server; server_name $hostname; access_log /var/log/nginx/webvirtmgr_access_log; location /static/ { root /var/www/webvirtmgr/webvirtmgr; # or /srv instead of /var expires max; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for; proxy_set_header Host $host:$server_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; client_max_body_size 1024M; # Set higher depending on your needs } }Case 1 - Badly configured websocket and listening IP adress of VM.
In this case vm confing on virtualization machine 2 is configured in this way:
It is listening on localhost and there is automatic vnc port and no websocket.
Clicking on console button on webvirtmgr interface causes opening console window with attempted VNC hanshake and then ending with:
Failed to connect to server (code: 1006)
Debug log of webvirtmgr-console:
2016-01-18 09:51:23,193 - root - DEBUG : Connexion infos : - connhost : '192.168.0.200' - connport : '22' - connuser : 'tcpsocketlibvirt@virt2.company.tld' - conntype : '1' - console_host : '127.0.0.1' - console_port : '5903' - console_socket : 'None' 13: 192.168.0.10: Plain non-SSL (ws://) WebSocket connection 13: 192.168.0.10: Version hybi-13, base64: 'False' 13: Need a tunnel to access console but can't mount one because it's not a SSH host 13: handler exception: No module named websockify 13: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/novnc/websocket.py", line 730, in top_new_client self.new_client() File "/var/www/webvirtmgr/console/webvirtmgr-console", line 234, in new_client self._new_client(daemon, socket_factory) File "/var/www/webvirtmgr/console/webvirtmgr-console", line 78, in from websockify import WebSocketProxy ImportError: No module named websockifyIn this case is browser connecting to newly opened console window webvirtmgr.company.tld:6080 (192.168.0.10:6080)
Which is correct.
Case 2 - Correctly configured websocket and listening IP adress of VM.
In this case vm confing on virtualization machine 2 is configured in this way:It is listening on all public interfaces and there is automatic websocket and vnc port.
Clicking on console button on webvirtmgr interface causes opening console window with:
noVNC ready: native WebSockets, canvas rendering
and then ending with: Server disconnected (code: 1006)
There is no log entry in webvirtmgr-console.
In this case is browser connecting to newly opened console window webvirtmgr.company.tld:5700 (192.168.0.10:5700) instead of webvirtmgr.company.tld:6080 (192.168.0.10:6080) Which is incorrect.
There is no listening port 5700 on webvirtmgr.company.tld!!!
Case 3 Websocket of VM configured manually to port 6080.
In this case vm confing on virtualization machine 2 is configured in this way:
Clicking on console button on webvirtmgr interface causes opening console window with:
Connected (unencrypted) to: QEMU(vmname)
And voilà console is working!!!
Debug log of webvirtmgr-console: 2016-01-18 10:30:39,716 - root - DEBUG : Connexion infos : - connhost : '192.168.0.200' - connport : '22' - connuser : 'tcpsocketlibvirt@virt2.company.tld' - conntype : '1' - console_host : '0.0.0.0' - console_port : '5901' - console_socket : 'None' 28: 192.168.0.10: Plain non-SSL (ws://) WebSocket connection 28: 192.168.0.10: Version hybi-13, base64: 'False' 28: connecting to: 192.168.0.200:5901 Traffic Legend: } - Client receive }. - Client receive partial { - Target receive > - Target send >. - Target send partial < - Client send <. - Client send partial 28: Start proxying {<}>{<}>{<}>{<}>{<{<}>{<{<{<}>..In this case is browser connecting to newly opened console window webvirtmgr.company.tld:6080 (192.168.0.10:6080)
Which is correct.
It is behaving the same way if I configure it to SSL listening on port 443.
So is this BUG or I'm missing some kind of configuration info here? Does anybody facing the same kind of behavior or is it just me?
Thanks for response.
@bentalexanderhaase commented on GitHub (Jun 21, 2016):
Thanks @majales for the deep research on this issue. Your thread is gold, thank you!
I hope this will be fixed some day ;)