From 0e801a9e6222afa4268416364b87f620bc42ae88 Mon Sep 17 00:00:00 2001 From: Stephen Finucane Date: Fri, 28 Sep 2018 18:13:32 +0100 Subject: [PATCH] doc: Rewrite the console doc The link between the various consoles was never well understood (by me, at least). Clarify this by restructuring the document to highlight the few differences between these services. Change-Id: I08991796aaced2abc824f608108c0c786181eb65 --- doc/source/admin/remote-console-access.rst | 589 ++++++++++++--------- 1 file changed, 346 insertions(+), 243 deletions(-) diff --git a/doc/source/admin/remote-console-access.rst b/doc/source/admin/remote-console-access.rst index f5a2f01556..b8a48c22b8 100644 --- a/doc/source/admin/remote-console-access.rst +++ b/doc/source/admin/remote-console-access.rst @@ -2,77 +2,32 @@ Configure remote console access =============================== -To provide a remote console or remote desktop access to guest virtual machines, -use VNC, SPICE HTML5 or Serial through either the OpenStack dashboard or the -command line. Best practice is to select only one of them to run. +OpenStack provides a number of different methods to interact with your guests: +VNC, SPICE, Serial, RDP or MKS. If configured, these can be accessed by users +through the OpenStack dashboard or the command line. This document outlines how +these different technologies can be configured -.. _about-nova-consoleauth: -About nova-consoleauth ----------------------- +Overview +-------- -The client proxies leverage a shared service to manage token authentication -called ``nova-consoleauth``. 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. +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: -Do not confuse the ``nova-consoleauth`` shared service with ``nova-console``, -which is a XenAPI-specific service that most recent VNC proxy architectures do -not use. +- Provide a bridge between the public network where the clients live and the + private network where the servers with consoles live. -.. deprecated:: 18.0.0 +- Mediate token authentication. - ``nova-consoleauth`` is deprecated since 18.0.0 (Rocky) and will be removed - in an upcoming release. +- Transparently handle hypervisor-specific connection details to provide a + uniform client experience. -SPICE console -------------- - -OpenStack Compute supports VNC consoles to guests. 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 to the ``nova-spicehtml5proxy`` service by using -SPICE-over-websockets. The ``nova-spicehtml5proxy`` service communicates -directly with the hypervisor process by using SPICE. - -VNC must be explicitly disabled to get access to the SPICE console. Set the -``vnc_enabled`` option to ``False`` in the ``[DEFAULT]`` section to disable the -VNC console. - -Use the following options to configure SPICE as the console for OpenStack -Compute: - -.. code-block:: console - - [spice] - agent_enabled = False - enabled = True - html5proxy_base_url = http://IP_ADDRESS:6082/spice_auto.html - html5proxy_host = 0.0.0.0 - html5proxy_port = 6082 - keymap = en-us - server_listen = 127.0.0.1 - server_proxyclient_address = 127.0.0.1 - -Replace ``IP_ADDRESS`` with the management interface IP address of the -controller or the VIP. - -VNC console proxy ------------------ - -The VNC proxy is an OpenStack component that enables compute service users to -access their instances through VNC clients. - -.. note:: - - The web proxy console URLs do not support the websocket protocol scheme - (ws://) on python versions less than 2.7.4. - -The VNC console connection works as follows: +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: #. A user connects to the API and gets an ``access_url`` such as, ``http://ip:port/?token=xyz``. @@ -81,33 +36,149 @@ The VNC console connection works as follows: #. The browser or client connects to the proxy. -#. The proxy talks to ``nova-consoleauth`` to authorize the token for the user, - and maps the token to the *private* host and port of the VNC server for an - instance. +#. The proxy talks to :program:`nova-consoleauth` to authorize 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 ``nova.conf`` file option, ``server_proxyclient_address``. In + through the :oslo.config:option:`vnc.server_proxyclient_address` option. In this way, the VNC proxy works as a bridge between the public network and private host network. #. The proxy initiates the connection to VNC server and continues to proxy until the session ends. -The proxy also tunnels the VNC protocol over WebSockets so that the ``noVNC`` -client can talk to VNC servers. In general, the VNC proxy: +This means a typical deployment with noVNC-based VNC consoles will have the +following components: -- Bridges between the public network where the clients live and the private - network where VNC servers live. +- An instance of the :program:`nova-consoleauth` service. Typically runs on the + controller host. -- Mediates token authentication. +- One or more :program:`nova-novncproxy` service. Supports browser-based noVNC + clients. For simple deployments, this service typically runs on the same + machine as :program:`nova-api` because it operates as a proxy between the + public network and the private compute host network. -- Transparently deals with hypervisor-specific connection details to provide a - uniform client experience. +- One or more :program:`nova-compute` services. Hosts the instances for which + consoles are provided. + +This particular example is illustrated below. .. figure:: figures/SCH_5009_V00_NUAC-VNC_OpenStack.png :alt: noVNC process :width: 95% + +.. _about-nova-consoleauth: + +About ``nova-consoleauth`` +-------------------------- + +The :doc:`/cli/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 :program:`nova-consoleauth` service in a cluster +configuration. + +.. important:: + + Do not confuse the :program:`nova-consoleauth` shared service with + :doc:`/cli/nova-console` service, which is a XenAPI-specific service that + most recent VNC proxy architectures do not use. + +.. deprecated:: 18.0.0 + + ``nova-consoleauth`` is deprecated since 18.0.0 (Rocky) and will be removed + in an upcoming release. + + +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. + +.. note:: + + It has `been reported`__ that versions of noVNC older than 0.6 do not work + with the :program:`nova-novncproxy` service. + + If using non-US key mappings, you need at least noVNC 1.0.0 for `a fix`__. + + __ https://bugs.launchpad.net/nova/+bug/1752896 + __ https://github.com/novnc/noVNC/commit/99feba6ba8fee5b3a2b2dc99dc25e9179c560d31 + +Configuration +~~~~~~~~~~~~~ + +To enable the noVNC VNC console service, you must configure both the +:program:`nova-novncproxy` service and the :program:`nova-compute` service. +Most options are defined in the :oslo.config:group:`vnc` group. + +The :program:`nova-novncproxy` service accepts the following options. + +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`vnc.novncproxy_host` +- :oslo.config:option:`vnc.novncproxy_port` + +In addition, if using the libvirt compute driver and enabling +:ref:`vnc-security`, the following additional options are accepted. + +- :oslo.config:option:`vnc.auth_schemes` +- :oslo.config:option:`vnc.vencrypt_client_key` +- :oslo.config:option:`vnc.vencrypt_client_cert` +- :oslo.config:option:`vnc.vencrypt_ca_certs` + +Similarly, if using the VMware compute driver, the following additional options +are accepted. + +- :oslo.config:option:`vmware.vnc_port` +- :oslo.config:option:`vmware.vnc_port_total` + +For example, to configure this via a ``nova-novncproxy.conf`` file: + +.. code-block:: console + + [vnc] + novncproxy_host = 0.0.0.0 + novncproxy_port = 6082 + +.. note:: + + This doesn't show configuration with security. For information on how to + configure this, refer to :ref:`vnc-security` below. + +The :program:`nova-compute` service requires the following options to configure +noVNC-based VNC console support. + +- :oslo.config:option:`vnc.enabled` +- :oslo.config:option:`vnc.novncproxy_base_url` +- :oslo.config:option:`vnc.server_listen` +- :oslo.config:option:`vnc.server_proxyclient_address` +- :oslo.config:option:`vnc.keymap` + +For example, to configure this via a ``nova.conf`` file: + +.. code-block:: console + + [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 + +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. + +.. _vnc-security: + VNC proxy security ~~~~~~~~~~~~~~~~~~ @@ -142,7 +213,7 @@ certificates: The authority certificate used to sign ``server-cert.pem`` and sign the VNC proxy server certificates. -The certificates must have v3 basic constraints [3]_ present to indicate the +The certificates must have v3 basic constraints [2]_ present to indicate the permitted key use and purpose data. We recommend using a dedicated certificate authority solely for the VNC @@ -151,7 +222,7 @@ for the OpenStack deployment. This is because libvirt does not currently have a mechanism to restrict what certificates can be presented by the proxy server. For further details on certificate creation, consult the QEMU manual page -documentation on VNC server certificate setup [2]_. +documentation on VNC server certificate setup [1]_. Configure libvirt to enable the VeNCrypt authentication scheme for the VNC server. In :file:`/etc/libvirt/qemu.conf`, uncomment the following settings: @@ -224,7 +295,7 @@ certificates to the noVNC proxy. The certificate authority cert used to sign ``client-cert.pem`` and sign the compute node VNC server certificates. -The certificates must have v3 basic constraints [3]_ present to indicate the +The certificates must have v3 basic constraints [2]_ present to indicate the permitted key use and purpose data. Once the certificates have been created, the noVNC console proxy service must @@ -237,161 +308,234 @@ be told where to find them. This requires editing :file:`nova.conf` to set. 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: +XVP-based VNC console +--------------------- -.. note:: +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. - To support :ref:`live migration `, - you cannot specify a specific IP address for ``server_listen``, because - that IP address does not exist on the destination host. +Configuration +~~~~~~~~~~~~~ -.. list-table:: **Description of VNC configuration options** - :header-rows: 1 - :widths: 25 25 +To enable the XVP VNC console service, you must configure both the +:program:`nova-xvpvncproxy` service and the :program:`nova-compute` service. +Most options are defined in the :oslo.config:group:`vnc` group. - * - Configuration option = Default value - - Description - * - **[DEFAULT]** - - - * - ``daemon = False`` - - (BoolOpt) Become a daemon (background process) - * - ``key = None`` - - (StrOpt) SSL key file (if separate from cert) - * - ``novncproxy_host = 0.0.0.0`` - - (StrOpt) Host on which to listen for incoming requests - * - ``novncproxy_port = 6080`` - - (IntOpt) Port on which to listen for incoming requests - * - ``record = False`` - - (BoolOpt) Record sessions to FILE.[session_number] - * - ``source_is_ipv6 = False`` - - (BoolOpt) Source is ipv6 - * - ``ssl_only = False`` - - (BoolOpt) Disallow non-encrypted connections - * - ``web = /usr/share/spice-html5`` - - (StrOpt) Run webserver on same port. Serve files from DIR. - * - **[vmware]** - - - * - ``vnc_port = 5900`` - - (IntOpt) VNC starting port - * - ``vnc_port_total = 10000`` - - vnc_port_total = 10000 - * - **[vnc]** - - - * - enabled = True - - (BoolOpt) Enable VNC related features - * - novncproxy_base_url = http://127.0.0.1:6080/vnc_auto.html - - (StrOpt) Location of VNC console proxy, in the form - "http://127.0.0.1:6080/vnc_auto.html" - * - server_listen = 127.0.0.1 - - (StrOpt) IP address on which instance vncservers should listen - * - server_proxyclient_address = 127.0.0.1 - - (StrOpt) The address to which proxy clients (like nova-xvpvncproxy) - should connect - * - xvpvncproxy_base_url = http://127.0.0.1:6081/console - - (StrOpt) Location of nova xvp VNC console proxy, in the form - "http://127.0.0.1:6081/console" +The :program:`nova-xvpvncproxy` service accepts the following options. -.. note:: +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`vnc.xvpvncproxy_host` +- :oslo.config:option:`vnc.xvpvncproxy_port` - - The ``server_proxyclient_address`` defaults to ``127.0.0.1``, which is - the address of the compute host that Compute instructs proxies to use when - connecting to instance servers. - - - For all-in-one XenServer domU deployments, set this to ``169.254.0.1.`` - - - For multi-host XenServer domU deployments, set to a ``dom0 management IP`` - on the same network as the proxies. - - - For multi-host libvirt deployments, set to a host management IP on the - same network as the proxies. - -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: +For example, to configure this via a ``nova-xvpvncproxy.conf`` file: .. code-block:: console - # apt-get install nova-novncproxy + [vnc] + xvpvncproxy_host = 0.0.0.0 + xvpvncproxy_port = 6081 -.. note:: +The :program:`nova-compute` service requires the following options to configure +XVP-based VNC support. - It has `been reported`_ that versions of noVNC older than 0.6 do not work - with the ``nova-novncproxy`` service. +- :oslo.config:option:`vnc.enabled` +- :oslo.config:option:`vnc.xvpvncproxy_base_url` +- :oslo.config:option:`vnc.server_listen` +- :oslo.config:option:`vnc.server_proxyclient_address` +- :oslo.config:option:`vnc.keymap` - If using non-US key mappings, then you need at least noVNC 1.0.0 for `a fix - `_. - -.. _been reported: https://bugs.launchpad.net/nova/+bug/1752896 - -The service starts automatically on installation. - -To restart the service, run: +For example, to configure this via a ``nova.conf`` file: .. code-block:: console - # service nova-novncproxy restart + [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 -The configuration option parameter should point to your ``nova.conf`` file, -which includes the message queue server address and credentials. +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. -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: +SPICE console +------------- -- ``server_listen=0.0.0.0`` +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. - 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. +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 :program:`nova-spicehtml5proxy` service +by using SPICE-over-websockets. The :program:`nova-spicehtml5proxy` service +communicates directly with the hypervisor process by using SPICE. - .. code-block:: console +Configuration +~~~~~~~~~~~~~ - +.. important:: - .. note:: + VNC must be explicitly disabled to get access to the SPICE console. Set the + :oslo.config:option:`vnc.enabled` option to ``False`` to disable the + VNC console. - To use live migration, use the 0.0.0.0 address. +To enable the SPICE console service, you must configure both the +:program:`nova-spicehtml5proxy` service and the :program:`nova-compute` +service. Most options are defined in the :oslo.config:group:`spice` group. -- ``server_proxyclient_address=127.0.0.1`` +The :program:`nova-spicehtml5proxy` service accepts the following options. - The address of the compute host that Compute instructs proxies to use when - connecting to instance ``vncservers``. +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`spice.html5proxy_host` +- :oslo.config:option:`spice.html5proxy_port` -Frequently asked questions about VNC access to virtual machines -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For example, to configure this via a ``nova-spicehtml5proxy.conf`` file: + +.. code-block:: console + + [spice] + html5proxy_host = 0.0.0.0 + html5proxy_port = 6082 + +The :program:`nova-compute` service requires the following options to configure +SPICE console support. + +- :oslo.config:option:`spice.enabled` +- :oslo.config:option:`spice.agent_enabled` +- :oslo.config:option:`spice.html5proxy_base_url` +- :oslo.config:option:`spice.server_listen` +- :oslo.config:option:`spice.server_proxyclient_address` +- :oslo.config:option:`spice.keymap` + +For example, to configure this via a ``nova.conf`` file: + +.. code-block:: console + + [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 + +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. + + +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: + +.. figure:: figures/serial-console-flow.svg + :width: 100% + :alt: The serial console flow + +1. The user requests a serial console connection string for an instance + from the REST API. +2. The :program:`nova-api` service asks the :program:`nova-compute` service, + which manages that instance, to fulfill that request. +3. That connection string gets used by the user to connect to the + :program:`nova-serialproxy` service. +4. The :program:`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 into the KVM guest. + +Configuration +~~~~~~~~~~~~~ + +To enable the serial console service, you must configure both the +:program:`nova-serialproxy` service and the :program:`nova-compute` service. +Most options are defined in the :oslo.config:group:`serial_console` group. + +The :program:`nova-serialproxy` service accepts the following options. + +- :oslo.config:option:`daemon` +- :oslo.config:option:`ssl_only` +- :oslo.config:option:`source_is_ipv6` +- :oslo.config:option:`cert` +- :oslo.config:option:`key` +- :oslo.config:option:`web` +- :oslo.config:option:`serial_console.serialproxy_host` +- :oslo.config:option:`serial_console.serialproxy_port` + +For example, to configure this via a ``nova-serialproxy.conf`` file: + +.. code-block:: console + + [serial_console] + serialproxy_host = 0.0.0.0 + serialproxy_port = 6083 + +The :program:`nova-compute` service requires the following options to configure +serial console support. + +- :oslo.config:option:`serial_console.enabled` +- :oslo.config:option:`serial_console.base_url` +- :oslo.config:option:`serial_console.proxyclient_address` +- :oslo.config:option:`serial_console.port_range` + +For example, to configure this via a ``nova.conf`` file: + +.. code-block:: console + + [serial_console] + enabled = True + base_url = ws://IP_ADDRESS:6083/ + proxyclient_address = 127.0.0.1 + port_range = 10000:20000 + +Replace ``IP_ADDRESS`` with the IP address from which the proxy is accessible +by the outside world. For example, this may be the management interface IP +address of the controller or the VIP. + +There are some things to keep in mind when configuring these options: + +* :oslo.config:option:`serial_console.serialproxy_host` is the address the + :program:`nova-serialproxy` service listens to for incoming connections. +* :oslo.config:option:`serial_console.serialproxy_port` must be the same value + as the port in the URI of :oslo.config:option:`serial_console.base_url`. +* The URL defined in :oslo.config:option:`serial_console.base_url` will form + part of the response the user will get when asking for a serial console + connection string. This means it needs to be an URL the user can connect to. +* :oslo.config:option:`serial_console.proxyclient_address` will be used by the + :program:`nova-serialproxy` service to determine where to connect to for + proxying the console interaction. + + +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 + 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 @@ -467,50 +611,9 @@ Frequently asked questions about VNC access to virtual machines console connections, make sure that the value of ``novncproxy_base_url`` is set explicitly where the ``nova-novncproxy`` service is running. -Serial Console --------------- - -The *serial console* feature [1]_ in nova is an alternative for graphical -consoles like *VNC*, *SPICE*, *RDP*. 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: - -.. figure:: figures/serial-console-flow.svg - :width: 100% - :alt: The serial console flow - -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 into the KVM guest. - -The config options for those nodes, which are in the section -``[serial_console]`` of your ``nova.conf``, are not intuitive at first. -Keep these things in mind: - -* The ``serialproxy_host`` is the address the `nova-serialproxy` service - listens to for incoming connections (see step 3). -* The ``serialproxy_port`` value must be the very same as in the URI - of ``base_url``. -* The ``base_url`` on the compute node will be part of the response the user - will get when asking for a serial console connection string (see step 1 - from above). This means it needs to be an URL the user can connect to. -* The ``proxyclient_address`` on the compute node will be used by the - `nova-serialproxy` service to determine where to connect to for - proxying the console interaction. References ---------- -.. [1] https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html -.. [2] https://qemu.weilnetz.de/doc/qemu-doc.html#vnc_005fsec_005fcertificate_005fverify -.. [3] https://tools.ietf.org/html/rfc3280#section-4.2.1.10 +.. [1] https://qemu.weilnetz.de/doc/qemu-doc.html#vnc_005fsec_005fcertificate_005fverify +.. [2] https://tools.ietf.org/html/rfc3280#section-4.2.1.10