Propose a new API microversion for a spice-direct console.
This spec covers the functionality required to support a Kerbside style "spice-direct" console type. The biggest change is a new API microversion, although there is also some ancillary changes around other console functionality (encryption, sound, etc). Change-Id: If87e5ce2f1049b5276a12e64b71cc3088cc197ca
This commit is contained in:
Michael Still
parent
ae9a0631ea
commit
787ff3a7c1
|
|
@ -0,0 +1,343 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
libvirt SPICE direct consoles
|
||||
==========================================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/libvirt-spice-direct-consoles
|
||||
|
||||
This specification proposes modifications to Nova's libvirt driver to support
|
||||
"direct" SPICE VDI consoles. These consoles are "direct" in that they are not
|
||||
intended to use a HTML5 transcoding proxy to access, and instead the user would
|
||||
use a native SPICE client like `remote-viewer`. Such a facility enables a much
|
||||
richer virtual desktop experience that Nova current supports, in return for
|
||||
relatively minor changes to Nova.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
The SPICE protocol was added to Nova a long time ago, and still represents the
|
||||
richest and most performant option for remote desktops using Nova. However at
|
||||
the moment, Horizon's HTML5 transcoding proxy is the only way to access these
|
||||
SPICE consoles, and the HTML5 interface does not support many of the more novel
|
||||
features of the SPICE protocol, nor does it support high resolution desktops
|
||||
well.
|
||||
|
||||
The proposed solution is relatively simple -- add an API microversion which
|
||||
makes it possible to create a "spice-direct" console, and to lookup connection
|
||||
details for that console from the API. The new console type and microversion is
|
||||
required because we need to be able to lookup both the insecure and secure TCP
|
||||
ports for the console, as well as the hypervisor IP address. While this is
|
||||
similar to what the HTML5 proxy does, it is distinct enough to require an
|
||||
API change.
|
||||
|
||||
This specification also covers tweaks the to the libvirt domain XML to enrich
|
||||
the desktop experience provided by such a direct console, such as:
|
||||
|
||||
* requiring an encrypted connection
|
||||
* allowing concurrent users as supported by SPICE
|
||||
* USB device passthrough from client to guest
|
||||
* sound support
|
||||
|
||||
The proposed changes allow direct connection to a SPICE console from a SPICE
|
||||
native client like `remote-viewer`. Without additional software, this implies
|
||||
that such a client would have network connectivity to relatively arbitrary TCP
|
||||
ports on the hypervisor hosting the instance. However, a SPICE protocol native
|
||||
proxy now exists, and a parallel proposal to this one proposes adding support
|
||||
for it to Kolla-Ansible. This proxy is called Kerbside, and more details are
|
||||
available at https://github.com/shakenfist/kerbside. That is, with the proxy
|
||||
deployed there is effectively no change to the network exposure of Nova
|
||||
hypervisors.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
*As a developer, I don't want these changes to make the Nova codebase even more
|
||||
complicated.* The changes proposed a relatively contained -- a single new API
|
||||
microversion, some changes to the domain XML generation code, and associated
|
||||
tests.
|
||||
|
||||
*As a deployer, I want to be able to use OpenStack to provide rich virtual
|
||||
desktops to my users.* This change facilitates such functionality, but does
|
||||
require additional deployment steps such as setup to TLS certificates for your
|
||||
hypervisors and management of a SPICE native proxy. There is a sample
|
||||
implementation using Kolla-Ansible available, but other deployment systems
|
||||
would need to integrate this functionality for it to be generally available.
|
||||
|
||||
*As a deployer who doesn't want rich desktop consoles, I don't want this
|
||||
functionality to complicate my deployment.* When disabled, the changes to
|
||||
deployments are minor -- for example the extra USB passthrough devices and
|
||||
sound devices in the domain XML are all deployer configurable and can be
|
||||
disabled.
|
||||
|
||||
*As an end user, I would like access to a richer desktop experience than is
|
||||
currently available.* Once these changes are integrated and Kerbside deployed,
|
||||
a further change to either Horizon or Skyline will be required to orchestrate
|
||||
console access via Kerbside. It is expected the complete end to end
|
||||
functionality will take several releases to land before a fully seamless
|
||||
experience is available. Once fully implemented, Horizon and Skyline will be
|
||||
capable of delivering a `.vv` configuration file for a specific console to a
|
||||
client, who will then have seamless access to their virtual desktop.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
As part of prototyping this functionality, a series of patches to Nova were
|
||||
developed. These are available at XXX. They are:
|
||||
|
||||
* Allow Nova to require secured SPICE connections, via a new `require_secure`
|
||||
configuration option in the SPICE configuration group.
|
||||
* Add an API microversion to expose SPICE "direct" consoles.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Unfortunately the SPICE HTML5 proxy does not meet the needs to many remote
|
||||
desktop users. Realistically OpenStack does not currently have a way of
|
||||
providing these rich desktop consoles to users. Instead, other systems such as
|
||||
Citrix are used for this functionality.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
This specification adds a new console type, "spice-direct", which provides
|
||||
the connection information required to talk the native SPICE protocol
|
||||
directly to qemu on the hypervisor. This is intended to be fronted
|
||||
by a proxy which will handle authentication separately.
|
||||
|
||||
A new microversion is introduced which adds the type "spice-direct"
|
||||
to the existing "spice" protocol.
|
||||
|
||||
An example request:
|
||||
|
||||
```
|
||||
POST /servers/<uuid>/remote-consoles
|
||||
{
|
||||
"remote_console": {
|
||||
"protocol": "spice",
|
||||
"type": "spice-direct"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
An example response:
|
||||
|
||||
```
|
||||
{
|
||||
"remote_console": {
|
||||
"protocol": "spice",
|
||||
"type": "spice-direct",
|
||||
"host": "localhost",
|
||||
"port": 5900,
|
||||
"tls_port": 5901
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This implies that the JSON schema for `create` console call would change to
|
||||
something like this:
|
||||
|
||||
```
|
||||
create_v297 = {
|
||||
'type': 'object',
|
||||
'properties': {
|
||||
'remote_console': {
|
||||
'type': 'object',
|
||||
'properties': {
|
||||
'protocol': {
|
||||
'type': 'string',
|
||||
'enum': ['vnc', 'spice', 'rdp', 'serial', 'mks'],
|
||||
},
|
||||
'type': {
|
||||
'type': 'string',
|
||||
'enum': ['novnc', 'xvpvnc', 'spice-html5', 'spice-direct',
|
||||
'serial', 'webmks'],
|
||||
},
|
||||
},
|
||||
'required': ['protocol', 'type'],
|
||||
'additionalProperties': False,
|
||||
},
|
||||
},
|
||||
'required': ['remote_console'],
|
||||
'additionalProperties': False,
|
||||
}
|
||||
```
|
||||
|
||||
And that the JSON schema for the `get_spice_console` would change to
|
||||
something like this:
|
||||
|
||||
```
|
||||
get_spice_console_v297 = {
|
||||
'type': 'object',
|
||||
'properties': {
|
||||
'os-getSPICEConsole': {
|
||||
'type': 'object',
|
||||
'properties': {
|
||||
'type': {
|
||||
'type': 'string',
|
||||
'enum': ['spice-html5', 'spice-direct'],
|
||||
},
|
||||
},
|
||||
'required': ['type'],
|
||||
'additionalProperties': False,
|
||||
},
|
||||
},
|
||||
'required': ['os-getSPICEConsole'],
|
||||
'additionalProperties': False,
|
||||
}
|
||||
```
|
||||
|
||||
For a SPICE direct console, a return value like this would be returned:
|
||||
|
||||
```
|
||||
{
|
||||
'remote_console': {
|
||||
'protocol': 'spice',
|
||||
'type': 'spice-direct',
|
||||
'host': 'fakespiceconsole.com',
|
||||
'port': 6969,
|
||||
'tls_port': 6970
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Arguably none. Nova already exposes SPICE consoles on TCP ports on the
|
||||
hypervisor. The API functionality to discover the insecure port already exists
|
||||
for the purposes of the HTML5 transcoding proxy. While the proposed change
|
||||
makes this more directly accessible, it also adds support for TLS encryption
|
||||
of the consoles, and would require a misconfigured network to expose these
|
||||
ports to end users.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
As discussed, a complete implementation requires deployment systems to
|
||||
integrate the Kerbside SPICE proxy, as well as modifications to front ends
|
||||
such as Horizon and Skyline to orchestrate consoles via Kerbside. However,
|
||||
those are outside the scope of a Nova specification.
|
||||
|
||||
The following configuration options are added by the proposed changes:
|
||||
|
||||
* `spice.require_secure`: defaults to `False`, the current hard coded
|
||||
default. Whether to require secure TLS connections to SPICE consoles. If
|
||||
you're providing direct access to SPICE consoles instead of using the
|
||||
HTML5 proxy, you may wish those connections to be encrypted. If so, set
|
||||
this value to True. Note that use of secure consoles requires that you
|
||||
setup TLS certificates on each hypervisor.
|
||||
|
||||
* `spice.allow_concurrent`: defaults to `False`, the current hard coded
|
||||
default. Whether to allow concurrent access to SPICE consoles. SPICE
|
||||
supports multiple users accessing the same console simultaneously, with
|
||||
some reduced functionality for the second and subsequent users. Set this
|
||||
option to True to enable concurrent access to SPICE consoles.
|
||||
|
||||
* `spice.debug_logging`: defaults to `False`, the current hard coded
|
||||
default. Whether to emit SPICE debug logs or not to the qemu log. These
|
||||
debug logs are verbose, but can help diagnose some connectivity issues.
|
||||
|
||||
* `spice.sound_enabled`: defaults to `False`, the current hard coded
|
||||
default. Whether to include a sound device for instance when SPICE
|
||||
consoles are enabled. Configuring this on a per flavor or per image basis
|
||||
was considered, but the additional complexity doesn't seem justified
|
||||
compared to a sound device which emits no sound if the client isn't
|
||||
capable of using it. An `ich6` sound device is always used.
|
||||
|
||||
Additionally, if SPICE consoles are enabled, then USB passthrough devices are
|
||||
created in the guest. These devices are harmless if not used by a client
|
||||
capable of using USB passthrough.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None.
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
mikal
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Feature Liaison
|
||||
---------------
|
||||
|
||||
Liason needed.
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Land the patches at XXX in the order specified there, with any modifications
|
||||
requested by the Nova team during code review.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Testing graphical user interfaces in the gate is hard. However, test for the
|
||||
API microversion will be added, and manual testing of the console functionality
|
||||
has occurred on the prototype and will be redone as the patches land.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
The Operators Guide will need to be updated to cover the new functionality and
|
||||
configuration options. The End User's guide will need to be updated to
|
||||
explain usage once the functionality is fully integrated.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None.
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - 2024.2 Dalmatian
|
||||
- Introduced
|
||||
Loading…
Reference in New Issue