NOTE: Enabling the VNC listener will do so without regard to security group rules! If someone can access the network which the NC is on, then they could conceivably access the VNC server for all newly started instances on the affected NC! Please proceed with caution.
While trying to troubleshoot instance boot issues, you conclude that it would be helpful if you could have access to the instance's console (beyond what euca-get-console-output is able to provide). More precisely, you would like to have interactive access to the instance's console.
One option available to us is to enable VNC services on the NC where the instance is running.
- root access to the NC where the instance is running
- ability to stop/start the instance (ie, bfEBS instance), or,
- ability to start a new instance after the change has been made
Note: This change will have no effect if you migrate a running instance over to the NC where you have made this change.
Edit the file /etc/eucalyptus/libvirt.xsl on the NC
Search for the word 'graphics'. You should end up on a line which looks like the following:
<!-- <graphics type='vnc' port='-1' autoport='yes' keymap='en-us' -->
Note that the "<!--" and the "-->" are the beginning-of-comment and end-of-comment markers, respectively. We want to remove those comment markers, and enhance the change to listen on all IP addresses (the default is to listen on 127.0.0.1).
The result should look like this:
<graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' keymap='en-us' />
There is no requirement to restart any Eucalyptus components. The change will take effect the next time a new instance is started on this NC.
To verify that the instance is listening post-startup:
- on the NC:
- ps -ef | grep <instance ID>
- netstat -tulpn | grep <PID from ps command, above>
The above should show a listener on 0.0.0.0:5900, or if that port is already in use (the first VNC listener instance) then check for port 5901, 5902, etc.
Another approach to verifying the VNC service functionality would be to run netstat on the NC thusly:
- netstat -tulpn | grep qemu-kvm
[root@odc-f-04 ~]# netstat -tulpn | grep qemu-kvm
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 3335/qemu-kvm
tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 3356/qemu-kvm
tcp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN 3377/qemu-kvm
In the above example, there are 3 instances running with the VNC service listener. In order to verify which listener references which PID, we proceed as per the following example:
[root@odc-f-04 ~]# ps -ef | grep qemu-kvm | egrep "3335|3356|3377" | cut -c1-100
qemu 3335 1 3 15:41 ? 00:00:44 /usr/libexec/qemu-kvm -name guest=i-2c9cc602,debug-t
qemu 3356 1 3 15:41 ? 00:00:43 /usr/libexec/qemu-kvm -name guest=i-2a9f1164,debug-t
qemu 3377 1 2 15:41 ? 00:00:37 /usr/libexec/qemu-kvm -name guest=i-bd133454,debug-t
From the above outputs, we are able to conclude the following:
- PID 3335 is instance ID i-2c9cc602 which has the VNC service listening on 0.0.0.0:5900
- PID 3356 is instance ID i-2a9f1164 which has the VNC service listening on 0.0.0.0:5901
- PID 3377 is instance ID i-bd133454 which has the VNC service listening on 0.0.0.0:5902
Note: As a reminder, if you stop/start a bfEBS instance, it could end up running on another NC in the same availability zone.
To connect to it from your desktop, you would need a VNC viewer, plus desktop access to the NC in question for TCP ports starting at port 5900 (eg, the range of TCP ports from 5900 to 5910). Often a VNC client's port 0 maps to the server's port 5900, VNC client port 1 maps to the server's port 5901, etc. Ensure that you are connecting to the NC's IP address, and not the IP address of the instance itself.
To disable this feature, once troubleshooting is no longer required:
- revert the /etc/eucalyptus/libvirt.xsl file to the original pre-edit state
- terminate the instance in question, or if it is a bfEBS instance, stop, then start the instance