Bug 447070 - virt-manager don't handle vnc over ssh with non standard port
virt-manager don't handle vnc over ssh with non standard port
Product: Virtualization Tools
Classification: Community
Component: virt-manager (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Depends On:
  Show dependency treegraph
Reported: 2008-05-17 12:10 EDT by ClaesBas
Modified: 2010-03-16 13:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-03 15:23:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ClaesBas 2008-05-17 12:10:43 EDT
Description of problem:

Tunnel for VNC-console not working when connecting with SSH on other port then 22!

Version-Release number of selected component (if applicable):
virt-manager (0.5.3-0ubuntu10) on Ubuntu 8.04 desktop against
an Ununtu 8.04 server with libvirt (0.4.0-2ubuntu8).

How reproducible:

All the times..

Steps to Reproduce:
Move port of ssh to an other port then 22 in /etc/ssh/sshd_config (Port 22222).

Let one of your Qemu-guests have the line <graphics type='vnc' port='5900'/> in

Start virt-manager on your "admin-workstation"
with the command "virt-manager -c qemu+ssh://user@some_machine:22222/system".
(Yes it connects!)

Run the machine with VNC configured through the GUI.

Try to open the Console for the Running guest, not working!

Verify VNC through an own ssh-tunnel:
From an terminal create ssh-tunnel with: ssh -p22222 -L 5900:
Afterwords from an other terminal try vncviewer (and it works!)

Actual results:

Expected results:

Additional info:

Output from ~/.virt-manager/virt-manager.log on "Desktop":
DEBUG (manager:398) VM obsd64 started
DEBUG (console:440) Trying console login
DEBUG (console:454) Graphics console configured at
DEBUG (console:467) Starting connect process for some_machine:22222 5900
DEBUG (console:402) Spawning SSH tunnel to some_machine:22222, for
DEBUG (console:421) Tunnel PID 17 FD 4700
DEBUG (console:429) Shutting down tunnel PID 4700 FD 17
DEBUG (console:356) VNC disconnected
The "Debug-block" above repeats and repets...

Content on servers /var/log/libvirt/qemu/machine.log:
/usr/bin/qemu-system-x86_64 -M pc -no-kqemu -m 256 -smp 1 -nographic -monitor
pty -no-acpi -boot c -hda /tmp/test.img -net
nic,macaddr=00:16:3e:22:31:4f,vlan=0 -net tap,fd=10,script=,vlan=0 -usb 
char device redirected to /dev/pts/1

Yes I now that I have -nographic and sereal console on the guest, VNC works
anyway through my own ssh-tunnel described above. I could see that the server
listen on AFTER I started the guest from the remote virt-manager
(with the commands "lsof -ni" or "netstat -utanp").
Comment 1 ClaesBas 2008-05-17 12:51:09 EDT
If I reconfig ssh to listen to port 22 on the server it works!
Comment 2 ClaesBas 2008-05-17 15:08:04 EDT
virt-manager:details.py:open_tunnel is hardcoded to use port 22 for ssh!

argv = ["ssh", "ssh", "-p", "22"] 
if username:
    argv += ['-l', username]
argv += [ server, "nc", vncaddr, str(vncport) ]

BTW, why not use tunnelfunction inside of ssh with parameter -L instead of netcat?
(I don't understand how and where the pipe between ssh and nc is created anyway)
Comment 3 ClaesBas 2008-05-18 02:53:27 EDT
Now I see how you do the netcat tunnel (as a command "inside" of ssh)
Comment 4 ClaesBas 2008-05-18 17:25:19 EDT
Patch on "current":

--- a/src/virtManager/details.py	Tue May 13 15:59:25 2008 -0400
+++ b/src/virtManager/details.py	Sun May 18 23:07:37 2008 +0200
@@ -975,7 +975,11 @@ class vmmDetails(gobject.GObject):
-            argv = ["ssh", "ssh", "-p", "22"] 
+            if not server.count(":"):
+            	sshport = 22
+            else:
+            	(server, sshport) = server.split(":")
+            argv = ["ssh", "ssh", "-p", sshport] 
             if username:
                 argv += ['-l', username]
             argv += [ server, "nc", vncaddr, str(vncport) ]
Comment 5 Cole Robinson 2008-09-03 15:23:23 EDT
This patch was applied upstream.


Closing as UPSTREAM. Thanks for the contribution!

Note You need to log in before you can comment on or make changes to this bug.