Xen Cloud Platform: Access to VM console
XCP has various options for accessing VM consoles. This document describes some of the ways to access those consoles.
How it works
Xen has (at least) two distinct ways to access VM consoles. One - using the xc (XenConsole) device (in paravirtualized environment) and second - using a framebuffer (for PV) and/or VGA adapter (for HVM) serializing via VNC. Main idea behind XCP (the open source version of XenServer) is uniform access to all VM regardless their type, so to accomplish this an enterprise management API (xapi) uses vncterm to emulate VNC connection to console for text consoles. Unfortunately, due strict to security, VNCterm only listens on localhost of XCP host. When management tools such as XenCenter or OpenXenManager display the console, they using a special service that requires XenAPI session token and normal authorization. In this case VNC traffic is wrapped in HTTP and is difficult to access manually.
How to access consoles
There is (at least) three ways to gain access to VM consoles: using HTTP connection with suitable software, creating custom tunnels with vncterm connections from the XCP host to your own host, and direct access to the console (for PV only).
Access via management software
You can use management tools such as XenCenter, OpenXenManager, or Xen VNC Proxy (XVP) to access consoles. XenCenter is currently only available for Windows platforms. OpenXenManager (and its web counterpart XenWebManager) are under active development. Some limitations may include needing direct access to the system and needed to open ports on the server, making PNAT and DMZ scenarios more challenging. Another issue is that you need to configure server pools according to your needs. For example, by default the console is only available only for the pool master, so if you are running XCP on single computer, this computer will be the master, and if you using two or more hosts in single pool, by default, the first server in pool will be the master.
- XenCenter (www.citrix.com/xenserver) is available free from Citrix and as of version XCP 1.0 and XenCenter 5.6 FP1 is able manage XCP as well as Citrix XenServer.
- OpenXenManager is available for download: http://www.openxenmanager.com/
- XVP is available from http://www.xvpsource.org/
- See also: XCP Projects
Custom SSH tunneling
Note: this is not an official way to access consoles, but it is a relatively safe work around. It is extremely useful when requiring console access and you are not using XenCenter and have yet been able to set up something like XVP.
The main problem is that the VNC server for the console listens only on localhost on the host. So you cannot say something like 'vncviewer myxcphost:5901'. It will not work.
You must create a ssh tunnel to the XCP host and setup TCP forwarding from your localhost ports to the localhost ports on the remote SSH server (XCP host in this case). It seems that the default settings for the SSH server (at least on XCP 6.1) do not allow TCP forwarding, so this needs to be enabled before being able to get the TCP ports to forward properly to connect to the console.
Change /etc/ssh/sshd_config to include:
AllowTcpForwarding yes
Then restart SSHd. If you are connected via SSH, this will obviously cut you off.
/etc/init.d/sshd restart
You can now remotely connect to the XCP host and setup SSH port linking to access both the text and graphical consoles. The ports used for VNC console are 5901-5999, and the ports used for text console are 9501-9599. It will look like this:
!/bin/sh ssh \ -L 5901:127.0.0.1:5901 \ -L 5902:127.0.0.1:5902 \ -L 5903:127.0.0.1:5903 \ -L 5904:127.0.0.1:5904 \ ... -L 5999:127.0.0.1:5999 \ -L 9501:127.0.0.1:9501 \ -L 9502:127.0.0.1:9502 \ -L 9503:127.0.0.1:9503 \ ... -L 9599:127.0.0.1:9599 \ root@yourxencloudplatformhost
After that you can gain direct access to the VM consoles by using a vncviewer clinet (for example, xnvcviewer localhost:59XX). To determine what to fill in for XX, see below. Note: the command above creates mapping between the 'localhost' port on the host and the 'localhost' port on your machine. You can use any VNC client, but be aware that some may not work well (for example, users have reported problems with tkvnc on Linux) and users have reported that xvncviewer works well.
You can also connect to the text console (VT100) on localhost:9501...9599.
- set TERM=VT100 - telnet localhost 9501 - Ctrl+] and change mode 'mode character'
Now we need find 'XX' value for host. This is pretty tricky, as the port changes every time the VM migrates, shuts down, etc.
On the XCP host do command:
xe vm-list name-label=<YOUVMNAME> params=dom-id
You can use name-label or uuid or any other attributes to distinguish one VM from other.
Examples:
xe vm-list name-label=myfisrtvm params=dom-id xe vm-list uuid=cdb3aab4-af6f-e7df-5b4f-c9f421e532ee params=dom-id
You will get output like this:
dom-id ( RO) : 11
(note: value '-1' means no console avaible, usually meaning that VM is not running, use xe vm-list (without params) to see current status).
Now we have the dom-id. Let's look to xenstore:
For HVM xenstore-ls /local/domain/DOM-ID/console For PV xenstore-ls /local/domain/DOM-ID/serial
(no slash at end)
Example:
xenstore-ls /local/domain/11/console
You will get reply like this:
vnc-port = "5911" tty = "/dev/pts/12"
The "vnc-port =" line is our port.
Now (from you local machine, since that is where the SSH tunnel was created, from above) run `xvncviwer localhost:5911.`
(note, every reboot you will need to reconnect and reestablish the SSH tunnel(s)).
Hacking a vncterm
Note: this is very risky, you will expose unprotected console to 'wild world' and any 'hacker kids' will able to send you 'Alt-SysRq b' keys (regardless of vm login prompt) to reboot your VM.
Theory: vnterm listen on 127.0.0.1 and this is defined in helers code. You can change it to any address you like. File is /opt/xensource/libexec/vncterm-wrapper, variable is export VNCTERM_LISTEN="-v 127.0.0.1:1".
After that you shall allow connection in firewall to tcp ports 5901..5999 and restart host. After reboot consoles of your VM will be exposed to wild cruel world where anyone can be able to connect to you VM consoles without password.
Direct access to text consoles of PV domains
There is undocumented key in vmops.ml source code:
(* if we have a "disable_pv_vnc" entry in other_config we disable
VNC for PV *)
let disable_pv_vnc = List.mem_assoc "disable_pv_vnc" other_config in
if not disable_pv_vnc then Device.PV_Vnc.start ~xs domid ?statefile:vnc_statefile else 0
So it simple:
xe vm-param-set uuid=UUID other-config:disable_pv_vnc=true
before starting PV virtual machine, and you will be able to access console via xl console DOMID.
Other way is accessing console of currently running machine without prior reboot. This way may change in the future, so please check for updates on the xen-api mailing list. Also be careful as this methods disrupts normal XCP console access from management tools. So, beware and USE CAUTION (I repeat: you will not be able to connect to this consoles with OpenXenManager or XenCenter).
Also note this method is only available for PV guests with text consoles. It will not work for HVM and PV with framebuffer.
The basic idea is that VNCterm takes the text console and draws them in graphics. So, if we terminate the VNCterm associated with the guest console, we will be able to access text console (instead of VNCterm). Using QEMU to access guest terminals is also being discussed among the xapi developers.
Here simple script, doing all you need:
domid=`xe vm-list uuid=$1 params=dom-id --minimal`
hostuuid=`xe vm-list uuid=$1 params=resident-on --minimal`
hostname=`xe host-list uuid=$hostuuid params=name-label --minimal`
if [ "`hostname`-" == "$hostname-" ]
then
echo locally resident
ps aux|grep vnc|grep "/$domid/"|awk '{print $2}'|xargs kill >/dev/null 2>/dev/null
echo connecting, use ctrl-] to disconnect
/opt/xensource/bin/xl console $domid
else
echo resident on $hostname, domid=$domid
fi
simply run it with uuid of machine you like to see and you will get access to console OR get message about which host it resides.
Note that the VNCterm sessions are setup by Xapi, which calls the vncterm-wrapper which then runs vncterm.
