Configure remote console access¶

Overview¶

It is considered best practice to deploy only one of the consoles types and not all console types are supported by all compute drivers. Regardless of what option is chosen, a console proxy service is required. These proxy services are responsible for the following:

• Provide a bridge between the public network where the clients live and the private network where the servers with consoles live.
• Mediate token authentication.
• Transparently handle hypervisor-specific connection details to provide a uniform client experience.

For some combinations of compute driver and console driver, these proxy services are provided by the hypervisor or another service. For all others, nova provides services to handle this proxying. Consider a noVNC-based VNC console connection for example:

1. A user connects to the API and gets an access_url such as, http://ip:port/?path=%3Ftoken%3Dxyz.

2. The user pastes the URL in a browser or uses it as a client parameter.

3. The browser or client connects to the proxy.

4. The proxy authorizes the token for the user, and maps the token to the private host and port of the VNC server for an instance.

   The compute host specifies the address that the proxy should use to connect through the vnc.server_proxyclient_address option. In this way, the VNC proxy works as a bridge between the public network and private host network.

5. The proxy initiates the connection to VNC server and continues to proxy until the session ends.

This means a typical deployment with noVNC-based VNC consoles will have the following components:

• One or more nova-novncproxy service. Supports browser-based noVNC clients. For simple deployments, this service typically runs on the same machine as nova-api because it operates as a proxy between the public network and the private compute host network.
• One or more nova-compute services. Hosts the instances for which consoles are provided.

This particular example is illustrated below.

noVNC-based VNC console¶

VNC is a graphical console with wide support among many hypervisors and clients. noVNC provides VNC support through a web browser.

[vnc]
novncproxy_host = 0.0.0.0
novncproxy_port = 6082

[vnc]
enabled = True
novncproxy_base_url = http://IP_ADDRESS:6082/vnc_auto.html
server_listen = 127.0.0.1
server_proxyclient_address = 127.0.0.1
keymap = en-us

$ systemctl restart libvirtd.service

[vnc]
auth_schemes=vencrypt,none

[vnc]
vencrypt_client_key=/etc/pki/nova-novncproxy/client-key.pem
vencrypt_client_cert=/etc/pki/nova-novncproxy/client-cert.pem
vencrypt_ca_certs=/etc/pki/nova-novncproxy/ca-cert.pem

SPICE console¶

The VNC protocol is fairly limited, lacking support for multiple monitors, bi-directional audio, reliable cut-and-paste, video streaming and more. SPICE is a new protocol that aims to address the limitations in VNC and provide good remote desktop support.

SPICE support in OpenStack Compute shares a similar architecture to the VNC implementation. The OpenStack dashboard uses a SPICE-HTML5 widget in its console tab that communicates with the nova-spicehtml5proxy service by using SPICE-over-websockets. The nova-spicehtml5proxy service communicates directly with the hypervisor process by using SPICE.

[spice]
html5proxy_host = 0.0.0.0
html5proxy_port = 6082

[spice]
agent_enabled = False
enabled = True
html5proxy_base_url = http://IP_ADDRESS:6082/spice_auto.html
server_listen = 127.0.0.1
server_proxyclient_address = 127.0.0.1
keymap = en-us

Serial¶

Serial consoles provide an alternative to graphical consoles like VNC or SPICE. They work a little differently to graphical consoles so an example is beneficial. The example below uses these nodes:

• controller node with IP 192.168.50.100
• compute node 1 with IP 192.168.50.104
• compute node 2 with IP 192.168.50.105

Here’s the general flow of actions:

1. The user requests a serial console connection string for an instance from the REST API.
2. The nova-api service asks the nova-compute service, which manages that instance, to fulfill that request.
3. That connection string gets used by the user to connect to the nova-serialproxy service.
4. The nova-serialproxy service then proxies the console interaction to the port of the compute node where the instance is running. That port gets forwarded by the hypervisor (or ironic conductor, for ironic) to the guest.

[serial_console]
serialproxy_host = 0.0.0.0
serialproxy_port = 6083

[serial_console]
enabled = True
base_url = ws://IP_ADDRESS:6083/
proxyclient_address = 127.0.0.1
port_range = 10000:20000

RDP¶

RDP is a graphical console primarily used with Hyper-V. Nova does not provide a console proxy service for RDP - instead, an external proxy service, such as the wsgate application provided by FreeRDP-WebConnect, should be used.

[rdp]
enabled = True
html5_proxy_base_url = https://IP_ADDRESS:6083/

MKS¶

MKS is the protocol used for accessing the console of a virtual machine running on VMware vSphere. It is very similar to VNC. Due to the architecture of the VMware vSphere hypervisor, it is not necessary to run a console proxy service.

[mks]
enabled = True
mksproxy_base_url = https://127.0.0.1:6090/

XVP-based VNC console¶

VNC is a graphical console with wide support among many hypervisors and clients. Xen VNC Proxy (XVP) provides VNC support via a simple Java client.

[vnc]
xvpvncproxy_host = 0.0.0.0
xvpvncproxy_port = 6081

[vnc]
enabled = True
xvpvncproxy_base_url = http://IP_ADDRESS:6081/console
server_listen = 127.0.0.1
server_proxyclient_address = 127.0.0.1
keymap = en-us

About nova-consoleauth¶

The deprecated nova-consoleauth service provides a shared service to manage token authentication that the client proxies outlined below can leverage. This service must be running for either proxy to work. Many proxies of either type can be run against a single nova-consoleauth service in a cluster configuration.

Frequently Asked Questions¶

• Q: What is the difference between ``nova-xvpvncproxy`` and ``nova-novncproxy``?

  A: nova-xvpvncproxy, which ships with OpenStack Compute, is a proxy that supports a simple Java client. nova-novncproxy uses noVNC to provide VNC support through a web browser.

• Q: I want VNC support in the OpenStack dashboard. What services do I need?

  A: You need nova-novncproxy, nova-consoleauth, and correctly configured compute hosts.

• Q: When I use ``nova get-vnc-console`` or click on the VNC tab of the OpenStack dashboard, it hangs. Why?

  A: Make sure you are running nova-consoleauth (in addition to nova-novncproxy). The proxies rely on nova-consoleauth to validate tokens, and waits for a reply from them until a timeout is reached.

• Q: My VNC proxy worked fine during my all-in-one test, but now it doesn’t work on multi host. Why?

  A: The default options work for an all-in-one install, but changes must be made on your compute hosts once you start to build a cluster. As an example, suppose you have two servers:

  PROXYSERVER (public_ip=172.24.1.1, management_ip=192.168.1.1)
  COMPUTESERVER (management_ip=192.168.1.2)
  

  Your nova-compute configuration file must set the following values:

  [vnc]
  # These flags help construct a connection data structure
  server_proxyclient_address=192.168.1.2
  novncproxy_base_url=http://172.24.1.1:6080/vnc_auto.html
  xvpvncproxy_base_url=http://172.24.1.1:6081/console
  
  # This is the address where the underlying vncserver (not the proxy)
  # will listen for connections.
  server_listen=192.168.1.2
  

  Note

  novncproxy_base_url and xvpvncproxy_base_url use a public IP; this is the URL that is ultimately returned to clients, which generally do not have access to your private network. Your PROXYSERVER must be able to reach server_proxyclient_address, because that is the address over which the VNC connection is proxied.

• Q: My noVNC does not work with recent versions of web browsers. Why?

  A: Make sure you have installed python-numpy, which is required to support a newer version of the WebSocket protocol (HyBi-07+).

• Q: How do I adjust the dimensions of the VNC window image in the OpenStack dashboard?

  A: These values are hard-coded in a Django HTML template. To alter them, edit the _detail_vnc.html template file. The location of this file varies based on Linux distribution. On Ubuntu 14.04, the file is at /usr/share/pyshared/horizon/dashboards/nova/instances/templates/instances/_detail_vnc.html.

  Modify the width and height options, as follows:

  <iframe src="{{ vnc_url }}" width="720" height="430"></iframe>
  

• Q: My noVNC connections failed with ValidationError: Origin header protocol does not match. Why?

  A: Make sure the base_url match your TLS setting. If you are using https console connections, make sure that the value of novncproxy_base_url is set explicitly where the nova-novncproxy service is running.

References¶