配置远程控制台访问

OpenStack 提供了多种与您的虚拟机交互的方法:VNC、SPICE、Serial、RDP 或 MKS。如果配置了这些方法,用户可以通过 OpenStack 仪表板或命令行访问它们。本文档概述了如何配置这些不同的技术。

概述

最佳实践是仅部署一种控制台类型,并且并非所有控制台类型都受所有计算驱动程序支持。无论选择哪种选项,都需要一个控制台代理服务。这些代理服务负责以下事项

  • 在客户端所在的公共网络与控制台服务器所在的私有网络之间提供桥梁。

  • 调解令牌认证。

  • 透明地处理特定于超visor的连接细节,以提供统一的客户端体验。

对于计算驱动程序和控制台驱动程序的某些组合,这些代理服务由超visor或其他服务提供。对于所有其他情况,nova 提供了服务来处理此代理。例如,考虑基于 noVNC 的 VNC 控制台连接

  1. 用户连接到 API 并获取一个 access_url,例如,http://ip:port/?path=%3Ftoken%3Dxyz

  2. 用户将 URL 粘贴到浏览器中或将其用作客户端参数。

  3. 浏览器或客户端连接到代理。

  4. 代理为用户授权令牌,并将令牌映射到实例的 VNC 服务器的私有主机和端口。

    计算主机指定代理应通过 vnc.server_proxyclient_address 选项使用的连接地址。 这样,VNC 代理就像公共网络和私有主机网络之间的桥梁。

  5. 代理启动与 VNC 服务器的连接,并继续代理直到会话结束。

这意味着使用基于 noVNC 的 VNC 控制台的典型部署将具有以下组件

  • 一个或多个 nova-novncproxy 服务。支持基于浏览器的 noVNC 客户端。对于简单的部署,此服务通常与 nova-api-wsgi 位于同一台机器上,因为它充当公共网络和私有计算主机网络之间的代理。

  • 一个或多个 nova-compute 服务。托管提供控制台的虚拟机。

待办事项

下图引用了 nova-consoleauth,需要更新。

这个特定的例子如下所示。

noVNC process

consoleauth 配置:

consoleauth 接受以下选项

[consoleauth]
token_ttl = 1000                    # default value is 600 second
enforce_session_timeout = True      # default is False

支持的控制台:

基于 noVNC 的 VNC 控制台

VNC 是一种图形控制台,在许多超visor和客户端中都有广泛的支持。noVNC 通过 Web 浏览器提供 VNC 支持。

注意

据报道,早于 0.6 版本的 noVNC 与 nova-novncproxy 服务不兼容 此处

如果使用非美国键盘映射,则需要至少 noVNC 1.0.0 才能 修复

如果使用 VMware ESX/ESXi 超visor,则需要至少 noVNC 1.1.0 才能 修复

配置

要启用 noVNC VNC 控制台服务,必须配置 nova-novncproxy 服务和 nova-compute 服务。大多数选项在 vnc 组中定义。

nova-novncproxy 服务接受以下选项

如果使用 libvirt 计算驱动程序并启用 VNC 代理安全性,则支持以下其他选项

例如,要通过 nova-novncproxy.conf 文件进行配置

[vnc]
novncproxy_host = 0.0.0.0
novncproxy_port = 6082

注意

这不显示使用安全性配置。有关如何配置此项的信息,请参阅下面的 VNC 代理安全性

nova-compute 服务需要以下选项来配置基于 noVNC 的 VNC 控制台支持

如果使用 VMware 计算驱动程序,则支持以下其他选项

例如,要通过 nova.conf 文件进行配置

[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

IP_ADDRESS 替换为代理可以从外部世界访问的 IP 地址。例如,这可能是控制器管理接口的 IP 地址或 VIP。

VNC 代理安全性

使用 HTTPS 部署面向公众的 VNC 代理接口,以防止恶意方在租户用户和代理服务器之间的网络上进行攻击。使用 HTTPS 时,TLS 加密仅适用于租户用户和代理服务器之间的数据。代理服务器和计算节点实例之间的数据仍然未加密。为了提供后者保护,有必要为 VNC 在计算节点和 noVNC 代理服务器主机上启用 VeNCrypt 身份验证方案。

QEMU/KVM 计算节点配置

确保运行 QEMU/KVM 并使用 libvirt 的每个计算节点都已为其颁发一组证书。以下是所需的证书列表

  • /etc/pki/libvirt-vnc/server-cert.pem

    一个 x509 证书,由 VNC 服务器 提供。 CommonName 应该与计算节点的主主机名匹配。如果需要使用多个主机名或 IP 地址访问相同的计算节点,也可以使用 subjectAltName

  • /etc/pki/libvirt-vnc/server-key.pem

    用于生成 server-cert.pem 文件的私钥。

  • /etc/pki/libvirt-vnc/ca-cert.pem

    用于签署 server-cert.pem 并签署 VNC 代理服务器证书的颁发机构证书。

证书必须具有 v3 基本约束 [2],以指示允许的密钥用途和目的数据。

我们建议使用专门的证书颁发机构仅用于 VNC 服务。该颁发机构可以是 OpenStack 部署中使用的主证书颁发机构的子机构。这是因为 libvirt 当前没有机制来限制代理服务器可以提供的证书。

有关证书创建的更多详细信息,请参阅 QEMU 手册页文档中有关 VNC 服务器证书设置 [1]

配置 libvirt 以启用 VNC 服务器的 VeNCrypt 身份验证方案。在 /etc/libvirt/qemu.conf 中,取消注释以下设置

  • vnc_tls=1

    这指示 libvirt 在启动 QEMU 时启用 VeNCrypt 身份验证方案,并传递上述证书。

  • vnc_tls_x509_verify=1

    这指示 QEMU 要求所有 VNC 客户端提供有效的 x509 证书。假设 VNC 服务使用专门的证书颁发机构,则可以确保只有批准的 VNC 代理服务器才能连接到计算节点。

请确保为创建实例的进程提供正确的证书文件权限。请遵循 libvirt wiki 页面 [3] 以获取相同信息。

编辑 qemu.conf 后,必须重新启动 libvirtd 服务

$ systemctl restart libvirtd.service

更改不会应用于计算节点上任何现有的正在运行的虚拟机,因此应在启动任何实例之前进行此配置。

noVNC 代理服务器配置

noVNC 代理服务器最初仅支持 none 身份验证方案,该方案不进行任何检查。因此,有必要通过编辑 nova.conf 文件来启用 vencrypt 身份验证方案。

[vnc]
auth_schemes=vencrypt,none

vnc.auth_schemes 值应按首选顺序列出。如果在一个已经运行实例的现有部署中启用 VeNCrypt,则最初允许 noVNC 代理服务器使用 vencryptnone。确认所有计算节点都已为 VNC 启用 VeNCrypt 后,可以从 vnc.auth_schemes 值的列表中删除 none 选项。

此时,noVNC 代理将拒绝连接到任何不提供 VeNCrypt 的计算节点。

除了启用身份验证方案外,还需要向 noVNC 代理提供证书。

  • /etc/pki/nova-novncproxy/client-cert.pem

    一个 x509 证书,由 VNC 服务器 提供。虽然 libvirt/QEMU 当前不会对 CommonName 字段进行任何验证,但未来的版本将允许根据 CommonName 设置访问控制。 CommonName 字段应与控制器节点的主机名匹配。如果使用 HA 部署,可以将 Organization 字段配置为部署中所有控制台代理实例通用的值。这样可以避免每次添加或删除控制台代理实例时都需要修改每个计算节点的白名单。

  • /etc/pki/nova-novncproxy/client-key.pem

    用于生成 client-cert.pem 文件的私钥。

  • /etc/pki/nova-novncproxy/ca-cert.pem

    用于签署 client-cert.pem 并签署计算节点 VNC 服务器证书的证书颁发机构证书。

证书必须具有 v3 基本约束 [2],以指示允许的密钥用途和目的数据。

创建证书后,必须告知 noVNC 控制台代理服务在哪里找到它们。这需要编辑 nova.conf 来设置。

[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 控制台

VNC 协议相当有限,缺乏对多显示器、双向音频、可靠的剪切和粘贴、视频流等的支持。SPICE 是一种新的协议,旨在解决 VNC 中的限制,并提供良好的远程桌面支持。

OpenStack Compute 中的 SPICE 支持与 VNC 实现类似。OpenStack 仪表板在其控制台选项卡中使用 SPICE-HTML5 小部件,该小部件通过使用 SPICE-over-websockets 与 nova-spicehtml5proxy 服务通信。 nova-spicehtml5proxy 服务通过 SPICE 直接与超visor 进程通信。

配置

重要提示

必须显式禁用 VNC 才能访问 SPICE 控制台。将 vnc.enabled 选项设置为 False 以禁用 VNC 控制台。

要启用 SPICE 控制台服务,必须配置 nova-spicehtml5proxy 服务和 nova-compute 服务。大多数选项在 spice 组中定义。

nova-spicehtml5proxy 服务接受以下选项。

例如,要通过 nova-spicehtml5proxy.conf 文件进行配置

[spice]
html5proxy_host = 0.0.0.0
html5proxy_port = 6082

nova-compute 服务需要以下选项来配置 SPICE 控制台支持。

例如,要通过 nova.conf 文件进行配置

[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

IP_ADDRESS 替换为代理可以从外部世界访问的 IP 地址。例如,这可能是控制器管理接口的 IP 地址或 VIP。

可选地, nova-compute 服务支持以下其他选项来配置 SPICE 控制台的压缩设置(算法和模式)。

以及以下选项以要求连接受到 TLS 保护

串行控制台

串行控制台为 VNC 或 SPICE 等图形控制台提供了一种替代方案。它们的工作方式与图形控制台略有不同,因此提供一个示例会很有帮助。下面的示例使用这些节点

  • 控制器节点,IP 为 192.168.50.100

  • 计算节点 1,IP 为 192.168.50.104

  • 计算节点 2,IP 为 192.168.50.105

这是操作的一般流程

The serial console flow
  1. 用户从 REST API 请求实例的串行控制台连接字符串。

  2. nova-api-wsgi 服务会要求管理该实例的 nova-compute 服务来满足该请求。

  3. 该连接字符串被用户用来连接到 nova-serialproxy 服务。

  4. nova-serialproxy 服务然后将控制台交互代理到运行实例的计算节点的端口。该端口被 hypervisor(或 ironic conductor,对于 ironic)转发到 guest。

配置

要启用串行控制台服务,必须配置 nova-serialproxy 服务和 nova-compute 服务。大多数选项定义在 serial_console 组中。

nova-serialproxy 服务接受以下选项。

例如,要通过 nova-serialproxy.conf 文件进行配置

[serial_console]
serialproxy_host = 0.0.0.0
serialproxy_port = 6083

nova-compute 服务需要以下选项来配置串行控制台支持。

例如,要通过 nova.conf 文件进行配置

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

IP_ADDRESS 替换为代理可以从外部世界访问的 IP 地址。例如,这可能是控制器管理接口的 IP 地址或 VIP。

在配置这些选项时,有一些事情需要记住

MKS 控制台

MKS 是用于访问在 VMware vSphere 上运行的虚拟机的控制台的协议。它与 VNC 非常相似。由于 VMware vSphere hypervisor 的架构,无需运行控制台代理服务。

配置

要启用 MKS 控制台服务,只需配置 nova-compute 服务。所有选项都定义在 mks 组中。

nova-compute 服务需要以下选项来配置 MKS 控制台支持。

例如,要通过 nova.conf 文件进行配置

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

关于 nova-consoleauth

之前使用的已移除的 nova-consoleauth 服务以前用于提供共享服务来管理以下客户端代理可以利用的令牌身份验证。令牌身份验证已在 18.0.0 (Rocky) 中移动到数据库,并在 20.0.0 (Train) 中被移除。

常见问题解答

  • 问:我希望在 OpenStack 控制面板中支持 VNC。我需要哪些服务?

    答:您需要 nova-novncproxy 和正确配置的计算主机。

  • 问:我的 VNC 代理在我的 all-in-one 测试期间工作正常,但现在在多主机上不起作用。为什么?

    答:默认选项适用于 all-in-one 安装,但在开始构建集群后,必须对您的计算主机进行更改。例如,假设您有两台服务器

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

    您的 nova-compute 配置文件必须设置以下值

    [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
    
    # This is the address where the underlying vncserver (not the proxy)
    # will listen for connections.
    server_listen=192.168.1.2
    

    注意

    novncproxy_base_url 使用公共 IP;这是最终返回给客户端的 URL,客户端通常无法访问您的专用网络。您的 PROXYSERVER 必须能够访问 server_proxyclient_address,因为 VNC 连接是通过该地址进行代理的。

  • 问:我的 noVNC 不适用于最新版本的 Web 浏览器。为什么?

    答:请确保您已安装 python-numpy,这是支持较新版本的 WebSocket 协议 (HyBi-07+) 所必需的。

  • 问:如何调整 OpenStack 控制面板中 VNC 窗口图像的尺寸?

    答:这些值在 Django HTML 模板中是硬编码的。要更改它们,请编辑 _detail_vnc.html 模板文件。此文件的位置因 Linux 发行版而异。在 Ubuntu 14.04 上,该文件位于 /usr/share/pyshared/horizon/dashboards/nova/instances/templates/instances/_detail_vnc.html

    修改 widthheight 选项,如下所示

    <iframe src="{{ vnc_url }}" width="720" height="430"></iframe>
    
  • 问:我的 noVNC 连接因 ValidationError:Origin header protocol does not match 而失败。为什么?

    答:请确保 base_url 与您的 TLS 设置匹配。如果您正在使用 https 控制台连接,请确保 novncproxy_base_url 的值在运行 nova-novncproxy 服务的位置上显式设置。

  • 问:如何知道要更新哪个 nova 配置文件以设置特定的配置选项?

    答:首先,使用 ps -aux | grep nova 找出负责您想要进行的更改的 nova 服务。找到该服务后,通过 systemctl 检查该服务的状态。在状态输出中,将列出与各自路径关联的 conf 文件。

参考