Re: Odd X11 over SSH issue
Paul Kraus p...@kraus-haus.org writes: On Fri, Nov 23, 2012 at 4:31 PM, Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org wrote: Yup, I just have not had a chance to chase that one down, and given that it happens once per SSH session, has not been a high priority. I mentioned it in the spirit of full disclosure. I would chock it up to network slowness, but I do not see the same behavior with Firefox, xload, or xclock. That's not a fair comparison, because tunneling a whole X server involves passing a lot more events than tunneling an application to run on your local server. This is particularly painful because the X protocols are highly serial. The VIrtualBox GUI (not the underlying VM console) should be comparable to Firefox in terms of network load. Yes, xclock and xload are much lower overhead as they are simpler apps. The difference between Firefox (measured at under 10 seconds to open the window) and VirtualBox (measured at 157 seconds to open the window) indicates that _something_ is wrong. Sorry if I was unclear. Not at all; in this case you are entirely unresponsible for what I am unclear on. I was, in fact, thinking of the console. The console is, in fact, what I was thinking of. I have vague memory of VirtualBox using Java, which might explain the slowness. That's more in your area of expertise than mine. I can't back that up, though, so I may be way off. I am running 3 different VMs on this server (soon to be more :-). One is WIn 2008 server as an RDP host for a specific application, the others ar FreeBSD VMs, one for DNS and DHCP, and the other for email / webmail. I manage the underlying Win 2008 instance via RDP (and that is how the end users connect), the two FreeBSD VMs do not run a window manager at all and they are managed via SSH connections. I use the VBoxHeadless executable to run the VMs for production use. Normally I make config changes with the command line tool VBoxManage, but in this case I had a FreeBSD VM that was not booting so I needed the console (and to make various changes to the config). It is running the VBox management GUI on the physical layer server that I am having fits with. If it is a network/protocol issue, ssh makes it harder to troubleshoot. Verbose output from the initiating side might tell you what is happening, although you would probably need to do some log analysis to separate out the different channels. I went back and checked the truss output, and the EAGAIN errors aren't interesting; they just mean there was no input on a non-blocking read from the socket. You also might want to check with the VirtualBox support channels, the freebsd-emulation list, and other obvious suspects. Also, building with a different frontend might make the X connection more lightweight. Is there any particular reason you don't let the X server run remotely and attach to it with something more latency-friendly, like vnc? I would expect that to work vastly better on any OS, just because you get X (specifically, its tendency to head-of-line blocking) out of its own way. The short answer to why X11 via SSH and not VNC for the management is that I have not found a very clean way to have the VNC service running for root without manual intervention to start it. Yes, I know I could script it, but that adds one additional layer that needs to be supported. That makes sense. You shouldn't have to run an X server on the base level system at all. P.S. I did get my VM repaired, very slowly and painfully, but I still need to track down the VBox GUI issue. Being able to clone, import, and export VMs is one of the reasons I use them at all... Be well. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Odd X11 over SSH issue
On Fri, Nov 23, 2012 at 6:43 PM, Paul Kraus p...@kraus-haus.org wrote: I am seeing very poor response time running the VitrualBox GUI via X11 tunneled over SSH via the Internet. The issue _appears_ to be limited to the VBox GUI as Firefox is reasonable. I am well aware of the latency issues tunneling X11 over SSH across the Internet, but that is what we are stuck with for the moment. The server is running FreeBSD 9 and is patched as of about 4 weeks ago. I see the same thing. But doing the same thing with CentOS(that is, CentOSis the host that VirtualBox runs on) goes pretty fast. My guess is that it is related to QT. -- chs, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Odd X11 over SSH issue
I am seeing very poor response time running the VitrualBox GUI via X11
tunneled over SSH via the Internet. The issue _appears_ to be limited
to the VBox GUI as Firefox is reasonable. I am well aware of the
latency issues tunneling X11 over SSH across the Internet, but that is
what we are stuck with for the moment. The server is running FreeBSD 9
and is patched as of about 4 weeks ago.
Observations:
1. When I first SSH into the box I see a long delay after the SSH
tunnel is setup before being prompted for a password, and I do not
know if this delay is related to the VBox issue. Details below.
2. When I fire up VirtualBox it takes _minutes_ before the window
opens and each action (drawing contents, mouse clicks) takes
additional _minutes_. Looking at the VirtualBox process with truss I
see many, many errors of the form:
read(7,0x80193a02c,4096) ERR#35 'Resource temporarily
unavailable'
where fd 7 is a socket. I would chock it up to network slowness, but I
do not see the same behavior with Firefox, xload, or xclock. An xterm
is even pretty snappy. Timing firefox, it takes under 10 seconds to
draw the window and fill it. It takes about 2 to 3 seconds to draw the
menu after clicking on the menu widget. With VirtualBox is takes
_minutes_ for every action, so it is clearly a call that VirtualBox is
making, but I can't figure it out from the truss output. The
VirtualBox GUI works fine when run on the console or on the local
network (not via SSH). I have a local system that I think is
configured the same way (but much slower hardware) and the VirtualBox
GUI is reasonable via SSH about 10-20 seconds to open the window and
5-10 second response time to mouse clicks). It is only when it is
tunneled over SSH via the Internet that the problem appears.
Details below.
Any suggestions where to look ? Or am I barking up the wrong tree ?
{1-2-3-4-5-6-7-}
SSH details:
Mini1:~ user$ ssh -X -C -v root@a.b.c.d
OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to a.b.c.d [a.b.c.d] port 22.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/identity type -1
debug1: identity file /Users/user/.ssh/id_rsa type -1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 z...@openssh.com
debug1: kex: client-server aes128-ctr hmac-md5 z...@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'a.b.c.d' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user/.ssh/identity
debug1: Trying private key: /Users/user/.ssh/id_rsa
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
here there is a pause of 30 to 60 seconds
Password:
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
Last login: Fri Nov 23 11:20:26 2012 from e.f.g.h
FreeBSD 9.0-RELEASE-p3 (GENERIC) #0: Tue Jun 12 02:52:29 UTC 2012
{1-2-3-4-5-6-7-}
VBox Details (from truss):
10709: socket(PF_INET,SOCK_STREAM,6) = 7 (0x7)
10709: fcntl(7,F_SETFD,FD_CLOEXEC) = 0 (0x0)
10709: setsockopt(0x7,0x6,0x1,0x7fffc578,0x4,0x2) = 0 (0x0)
10709: setsockopt(0x7,0x,0x8,0x7fffc578,0x4,0x2) = 0 (0x0)
10709: connect(7,{ AF_INET 127.0.0.1:6010 },16) = 0 (0x0)
10709: getpeername(7,{ AF_INET 127.0.0.1:6010 },0x7fffc2d4) = 0 (0x0)
10709: __sysctl(0x7fffc2f0,0x2,0x7fffc340,0x7fffc2e8,0x0,0x0)
= 0 (0x0)
10709: access(/root/.Xauthority,4) = 0 (0x0)
10709: open(/root/.Xauthority,O_RDONLY,0666) = 8 (0x8)
10709: fstat(8,{
Re: Odd X11 over SSH issue
On Fri, Nov 23, 2012 at 11:43 AM, Paul Kraus p...@kraus-haus.org wrote: I am seeing very poor response time running the VitrualBox GUI via X11 tunneled over SSH via the Internet. The issue _appears_ to be limited to the VBox GUI as Firefox is reasonable. I am well aware of the latency issues tunneling X11 over SSH across the Internet, but that is what we are stuck with for the moment. The server is running FreeBSD 9 and is patched as of about 4 weeks ago. Start it with --graphicssystem native -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Odd X11 over SSH issue
On Fri, Nov 23, 2012 at 1:01 PM, Adam Vande More amvandem...@gmail.com wrote:
On Fri, Nov 23, 2012 at 11:43 AM, Paul Kraus p...@kraus-haus.org wrote:
I am seeing very poor response time running the VitrualBox GUI via X11
tunneled over SSH via the Internet. The issue _appears_ to be limited
to the VBox GUI as Firefox is reasonable. I am well aware of the
latency issues tunneling X11 over SSH across the Internet, but that is
what we are stuck with for the moment. The server is running FreeBSD 9
and is patched as of about 4 weeks ago.
Start it with --graphicssystem native
Tried it, did not make any noticeable difference, still over a
minute to open the window, but thanks for the suggestion. VBox is
version 4.1.22_OSE.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Principal Consultant, Business Information Technology Systems
- Deputy Technical Director, LoneStarCon 3 (http://lonestarcon3.org/)
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, Troy Civic Theatre Company
- Technical Advisor, RPI Players
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Odd X11 over SSH issue
Paul Kraus p...@kraus-haus.org writes: I am seeing very poor response time running the VitrualBox GUI via X11 tunneled over SSH via the Internet. The issue _appears_ to be limited to the VBox GUI as Firefox is reasonable. I am well aware of the latency issues tunneling X11 over SSH across the Internet, but that is what we are stuck with for the moment. The server is running FreeBSD 9 and is patched as of about 4 weeks ago. Observations: 1. When I first SSH into the box I see a long delay after the SSH tunnel is setup before being prompted for a password, and I do not know if this delay is related to the VBox issue. Details below. Running the ssh server with more debugging will probably tell you what's happening in this area. 2. When I fire up VirtualBox it takes _minutes_ before the window opens and each action (drawing contents, mouse clicks) takes additional _minutes_. Looking at the VirtualBox process with truss I see many, many errors of the form: read(7,0x80193a02c,4096) ERR#35 'Resource temporarily unavailable' where fd 7 is a socket. This could be a red herring. Or not. But you can't tell without tracing down exactly what the socket is, and what is expected to be read from it. Probably not the first path worth exploring, although you may need to go there eventually. I would chock it up to network slowness, but I do not see the same behavior with Firefox, xload, or xclock. That's not a fair comparison, because tunneling a whole X server involves passing a lot more events than tunneling an application to run on your local server. This is particularly painful because the X protocols are highly serial. Is there any particular reason you don't let the X server run remotely and attach to it with something more latency-friendly, like vnc? I would expect that to work vastly better on any OS, just because you get X (specifically, its tendency to head-of-line blocking) out of its own way. Be well. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Odd X11 over SSH issue
On Fri, Nov 23, 2012 at 4:31 PM, Lowell Gilbert
freebsd-questions-lo...@be-well.ilk.org wrote:
Observations:
1. When I first SSH into the box I see a long delay after the SSH
tunnel is setup before being prompted for a password, and I do not
know if this delay is related to the VBox issue. Details below.
Running the ssh server with more debugging will probably tell you what's
happening in this area.
Yup, I just have not had a chance to chase that one down, and
given that it happens once per SSH session, has not been a high
priority. I mentioned it in the spirit of full disclosure.
I would chock it up to network slowness, but I
do not see the same behavior with Firefox, xload, or xclock.
That's not a fair comparison, because tunneling a whole X server
involves passing a lot more events than tunneling an application to run
on your local server. This is particularly painful because the X
protocols are highly serial.
The VIrtualBox GUI (not the underlying VM console) should be
comparable to Firefox in terms of network load. Yes, xclock and xload
are much lower overhead as they are simpler apps. The difference
between Firefox (measured at under 10 seconds to open the window) and
VirtualBox (measured at 157 seconds to open the window) indicates that
_something_ is wrong.
Sorry if I was unclear. I am running 3 different VMs on this
server (soon to be more :-). One is WIn 2008 server as an RDP host for
a specific application, the others ar FreeBSD VMs, one for DNS and
DHCP, and the other for email / webmail. I manage the underlying Win
2008 instance via RDP (and that is how the end users connect), the two
FreeBSD VMs do not run a window manager at all and they are managed
via SSH connections. I use the VBoxHeadless executable to run the VMs
for production use. Normally I make config changes with the command
line tool VBoxManage, but in this case I had a FreeBSD VM that was not
booting so I needed the console (and to make various changes to the
config).
It is running the VBox management GUI on the physical layer server
that I am having fits with.
Is there any particular reason you don't let the X server run remotely
and attach to it with something more latency-friendly, like vnc? I would
expect that to work vastly better on any OS, just because you get X
(specifically, its tendency to head-of-line blocking) out of its own way.
The short answer to why X11 via SSH and not VNC for the management
is that I have not found a very clean way to have the VNC service
running for root without manual intervention to start it. Yes, I know
I could script it, but that adds one additional layer that needs to be
supported.
P.S. I did get my VM repaired, very slowly and painfully, but I still
need to track down the VBox GUI issue.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Principal Consultant, Business Information Technology Systems
- Deputy Technical Director, LoneStarCon 3 (http://lonestarcon3.org/)
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, Troy Civic Theatre Company
- Technical Advisor, RPI Players
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
