I had a sles11sp2 out-of-the-box install running - worked perfectly incl. remote administration on VNC.
Recently I added all “Needed updates” from online update. Now I am only able to connect on ssh, no remote administration on VNC.
I tried to disable and re-enable from yast, but no change.
The system is running in a secure environment with local (own) firewall disabled.
Additional info:
netstat -lpdn | grep 5901
tcp 0 0 127.0.0.1:5901 0.0.0.0:* LISTEN 14252/qemu-dm
lsof -i | grep 5901
qemu-dm 14252 root 22u IPv4 32643 0t0 TCP localhost:5901 (LISTEN)
do I see it right that you’re talking about administering a DomU? Because it’s qemu that is listening on that port.
Your Dom0 (“host”) is SLES11SP1, your guest (DomU) is SLES11SP2, and it’s the guest then that you updates to the latest patches?
Anyhow, what does "xm list -l " tell you about the VNC setup?
And from where do you try to remotely administer, from Dom0 or from a different system? As your about output from lsof shows, the server is only listening on the localhost interface of Dom0 (127.0.0.1:5901), thus any remote connection will fail.
So:
if you’re using Xen on SLES11 (Dom0)
and want to VNC-connect to that DomU from a different server than you Dom0,
check “/etc/xen/xend-config.sxp” for the “vnc-listen” statement, which I assume to limit things to 127.0.0.1, and change that to
#(vnc-listen '127.0.0.1')
(vnc-listen '0.0.0.0')
and restart xend (and, unfortunately, your DomU, too) to be able to access the DomU via VNC from a remote machine (if the remainder of the networking setup is correct ).
Hi,
no - I might be unclear, but it is my host (sles11sp1) that gives me the problems. No XEN involved here. (Well it is the xen kernel booted)
(But actually I have VNC access to my DomU’s)
/Regards
[QUOTE=clausbc;13061]Hi,
no - I might be unclear, but it is my host (sles11sp1) that gives me the problems. No XEN involved here. (Well it is the xen kernel booted)
(But actually I have VNC access to my DomU’s)
/Regards[/QUOTE]
sorry I mis-read that… but now you have me even more confused :[
If there’s “no xen involved here” (except that the server is running a xen kernel), where’s that qemu-dm coming from? Why were you grep’ing for port 5601 explicitly? Why not 5600?
No matter what, to get me back on track you probably need to re-explain the problem you’re facing:
what client do you invoke where and how?
what error (message) do you face?
can you test by invoking the cmd line vnc version from Linux - vncviewer? What are the errors reported there?
Since access problems can be many-fold, as can be their sources, it’s about the details…
sorry I mis-read that… but now you have me even more confused :[
If there’s “no xen involved here” (except that the server is running a xen kernel), where’s that qemu-dm coming from? Why were you grep’ing for port 5601 explicitly? Why not 5600?
No matter what, to get me back on track you probably need to re-explain the problem you’re facing:
what client do you invoke where and how?
what error (message) do you face?
can you test by invoking the cmd line vnc version from Linux - vncviewer? What are the errors reported there?
Since access problems can be many-fold, as can be their sources, it’s about the details…
Regards,
Jens[/QUOTE]
Hi,
I grep for 5901, which is the standard VNC access port. Command directly on the server console.
No idea about the qemu-dm part. That’s part of my confusion as well.
I try to access the server from a Windows client running Realvnc viewer
I get “Connection refused” in the Realvnc viewer
/Regards
I grep for 5901, which is the standard VNC access port. Command directly on the server console. [/QUOTE]
Standard vnc access port for the first VNC instance is 5900 (5601 was a typo - not enough coffee this morning ) - which corresponds to " :0" in “VNC display terminology”. From the Xvnc man page:
So you might better check for any port number in the 5900++ range. And pay close attention to the local address it binds to - if that’s 127.0.0.1, you can only reach the vnc server from the local machine.
Anything reported by “xm list” on that server?
[QUOTE=clausbc;13065]- I try to access the server from a Windows client running Realvnc viewer
I get “Connection refused” in the Realvnc viewer
/Regards[/QUOTE]
verbosity+2, please . For example, to which port/display number do you try to connect to? “:0” (5900), “:1” (5901)?
AFAIR, remote graphical access is via Xvnc (sorry, no practical experience here, I’m using CLI do do work on servers), so you might want to check if Xvnc is running and if there’s any error indication in /var/log/X*.log.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…[/QUOTE]
Hi,
yes I have checked the kb, and I found the troubleshooting guide.
I “hit the wall” at:
Listening Port
Use the following command to verify that port 5901 is in a listening state and is owned by xinetd:
netstat -lpdn | grep 5901
The following should be displayed (other than a different PID which is fine):
tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 3351/xinetd
If this information is not displayed then it would indicate that the “Remote Administration (VNC)” selection in YaST has not been configured or the the xinetd service has been disabled (which can also be checked in YaST). Both selections can be found in the"Network Services" section of YaST.
This is my output: netstat -lpdn | grep 5901
tcp 0 0 127.0.0.1:5901 0.0.0.0:* LISTEN 25479/qemu-dm
If this information is not displayed then it would indicate that the
“Remote Administration (VNC)” selection in YaST has not been
configured or the the xinetd service has been disabled (which can
also be checked in YaST).[/color]
Is the xinetd service running?
server:~ # rcxinetd status
Checking for service xinetd: running
If not, what happens if you try to start it?
server:~ # rcxinetd start
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
you cannot have two services listening on the same port, so I strongly suggest to find out what that qemu-dm process is doing there. On a typical Xen server, this wouldn’t be out of the ordinary, but from what I’ve understood, there’s no DomU supposed to be running on this server?
you cannot have two services listening on the same port, so I strongly suggest to find out what that qemu-dm process is doing there. On a typical Xen server, this wouldn’t be out of the ordinary, but from what I’ve understood, there’s no DomU supposed to be running on this server?
Regards,
Jens[/QUOTE]
Hi Jens,
well yes - this is indeed a XEN host as well.
I have lost Remote administration access to this host
/Claus
[QUOTE=clausbc;13088]Hi Jens,
well yes - this is indeed a XEN host as well.
I have lost Remote administration access to this host
/Claus[/QUOTE]
that need not be. For one, you might be able to change the port (“display number”) where Remote Admin is listening - unfortunately I cannot help with that (I have yet to configure something like that ).
The other way around is feasible, too - for each DomU, you can configure the vnc port it is listening on (i.e. via vfb=[‘type=vnc,vncunused=1,vncdisplay=5’]). So while that is more work (you have to configure every DomU to an explicit port), it is possible. Any from my experience it is indeed helpful too, to be able to access the DomU via VNC without having to look up (via “xm list -l”) the display it is listening on .
In /etc/xinetd.d/vnc you can enable additional ports with different
configurations.
I don’t know why qemu-dm is listening on port 5901. It doesn’t happen
on my system. I don’t even know where it might be configured.
If nothing is listening on port 5902, maybe you can modify
/etc/xinetd.d/vnc to enable that port and see if you can use VNC on
5902. That would at least show that VNC is working and that maybe your
issue is a port conflict on port 5901.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
[QUOTE=KBOYLE;13092]I don’t know why qemu-dm is listening on port 5901. It doesn’t happen
on my system. I don’t even know where it might be configured.[/QUOTE]
xend will assign any DomU (shows as “qemu-dm”) that has VNC configured into it (i.e. for standard graphics console) port 5900, 5901, and so on. Unless you give it a separate port in the DomU’s config, that is.
Hi,
I tried enabling xinetd on the sencond display, that is port 5902.
VNC client connects - but shows only a black screen. No prompts, nothing
/Regards
I just configured this on a test VM - enabled remote administration in YaST, modified /etc/xinetd.d/vnc to only enable “vnc3”, restarted xinetd, and successfully connected via VNC (vncviewer my.test.server:3)
I tried enabling xinetd on the sencond display, that is port 5902.
VNC client connects - but shows only a black screen. No prompts, nothing
An important question is: What other VNC ports are blocked by active DomUs? You might be seeing the console of your third DomU
I recommend to set the port number to 5999 in /etc/xinetd.d/vnc (unless you have some DomU configured to that port) and try to connect to that. The lower port numbers (5900++) are easily used up by started DomUs…
[QUOTE=clausbc;13115]Hi,
I tried enabling xinetd on the sencond display, that is port 5902.
VNC client connects - but shows only a black screen. No prompts, nothing
/Regards[/QUOTE]
There are a couple of points worth mentioning about the information displayed.
As of SLES11 VNC does not, by default, have access to Display 0.
See TID 7003097 Enabling VNC Server on startup of the X server with SLE 11.
I have implemented the changes in this TID and that is likely why 7620/X is listening on port 5900. I use SSH/VNC for remote access and need access to Display 0 as soon as the server has rebooted.
In /etc/xinetd.d/vnc I have enable port 5902 which is why 6880/xinetd is listening on 5902.
It would appear that my DomU’s have been assigned ports sequentially from 5900 as long as they are not already used.
I don’t know why VNC is not working for you. Do you think TID 7003097 might help?
).
) - which corresponds to " :0" in “VNC display terminology”. From the Xvnc man page:
. For example, to which port/display number do you try to connect to? “:0” (5900), “:1” (5901)?