Problem with graphical console access to Xen domU on remote host

We are having a problem with the graphical console on our Cloudmin system. Our setup is as follows: cloud.example.com = Cloudmin master server (Xen is not installed - CentOS 5.5) host1.example.com = Xen host system (Debian Lenny - Xen 3.2.1) host2.example.com = Xen host system (Debian Lenny - Xen 3.2.1) client1.vps.example.com = User domU on host1 client2.vps.example.com = User domU on host2

Whenever a user is logged into Cloudmin on cloud.example.com and tries to use the graphical console to access their domU (clientX.vps.example.com), the console screen says "Status: connecting to cloud.example.com, port 5900" and subsequently fails with the message "Network error: could not connect to server: cloud.example.com:5900". This makes perfect sense as there is no VNC process listening on cloud.example.com. If an alias name is used to access cloud.example.com, for example cloudmaster.example.com, the same behavior is exhibited except that the "connecting to..." and "could not connect..." messages now reference cloudmaster.example.com. It appears that the viewer applet is attempting to connect to the VNC port on the hostname in the URL by which Cloudmin was accessed. It really should be attempting to access the host on which the user domU resides. In the above example, this would be host1.example.com.

If we attempt to access host1.example.com using a VNC client, VNC works beautifully. We are able to control the domUs without any problem.

Is there a setting somewhere that we have missed to configure this correctly? Maybe a bug in the vnc.cgi file? Some sort of VNC redirector that needs to be installed on the Cloudmin system?

TIA for your assistance.

Status: 
Closed (fixed)

Comments

That is actually intentional behavior - a java applet (like the one used for VNC console access) cannot connect to any host other than the one it was loaded from, in this case the cloudmin master.

When you use the Graphical Console page, the master starts listening on port 5900 which is then forwards to the appropriate port on the host. If this isn't working, make sure that ports 5900-5910 aren't blocked by a firewall on the master.

That took care of it. Thanks! I didn't see anything listening on port 5900 so I hadn't opened the firewall. Unfortunately, I didn't occur to me that the listener wasn't starting until the graphical console was accessed.