Configure remote console access¶

VNC proxy security¶

Deploy the public-facing interface of the VNC proxy with HTTPS to prevent attacks from malicious parties on the network between the tenant user and proxy server. When using HTTPS, the TLS encryption only applies to data between the tenant user and proxy server. The data between the proxy server and Compute node instance will still be unencrypted. To provide protection for the latter, it is necessary to enable the VeNCrypt authentication scheme for VNC in both the Compute nodes and noVNC proxy server hosts.

$ 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

VNC configuration options¶

To customize the VNC console, use the following configuration options in your nova.conf file:

Typical deployment¶

A typical deployment has the following components:

• A nova-consoleauth process. Typically runs on the controller host.
• One or more nova-novncproxy services. 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-xvpvncproxy services. Supports the special Java client discussed here. For simple deployments, this service typically runs on the same machine as nova-api because it acts as a proxy between the public network and the private compute host network.
• One or more compute hosts. These compute hosts must have correctly configured options, as follows.

nova-novncproxy (noVNC)¶

You must install the noVNC package, which contains the nova-novncproxy service. As root, run the following command:

# apt-get install nova-novncproxy

The service starts automatically on installation.

To restart the service, run:

# service nova-novncproxy restart

The configuration option parameter should point to your nova.conf file, which includes the message queue server address and credentials.

By default, nova-novncproxy binds on 0.0.0.0:6080.

To connect the service to your Compute deployment, add the following configuration options to your nova.conf file:

• server_listen=0.0.0.0

  Specifies the address on which the VNC service should bind. Make sure it is assigned one of the compute node interfaces. This address is the one used by your domain file.

  <graphics type="vnc" autoport="yes" keymap="en-us" listen="0.0.0.0"/>
  

  Note

  To use live migration, use the 0.0.0.0 address.

• server_proxyclient_address=127.0.0.1

  The address of the compute host that Compute instructs proxies to use when connecting to instance vncservers.

Frequently asked questions about VNC access to virtual machines¶

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