Xen Cloud Platform: Access to VM console

From Xen
Jump to navigationJump to search


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.

Custom SSH tunneling

Note: this is not an official way to access consoles, but it is a relatively safe work around.

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 XCP host:

This will looks like: 



!/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 5905:127.0.0.1:5905 \
-L 5906:127.0.0.1:5906 \
...
-L 5999:127.0.0.1:5999 \
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.

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: 

xenstore-ls /local/domain/DOM-ID/console

(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.

See also

Retrieved from "https://wiki.xenproject.org/index.php?title=Xen_Cloud_Platform:_Access_to_VM_console&oldid=2162"