1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
======================
Nova - Compute Service
======================
Nova is a core service in OpenStack, and provides compute services. Typically
this is via Virtual Machines (VMs), but may also be via bare metal servers if
Nova is coupled with Ironic.
Nova is enabled by default, but may be disabled by setting ``enable_nova`` to
``false`` in ``globals.yml``.
Virtualisation Drivers
======================
The virtualisation driver may be selected via ``nova_compute_virt_type`` in
``globals.yml``. Supported options are ``qemu`` and ``kvm``.
The default is ``kvm``.
Libvirt
-------
Information on the libvirt-based drivers ``kvm`` and ``qemu`` can be found in
:doc:`libvirt-guide`.
Bare Metal
----------
Information on using Nova with Ironic to deploy compute instances to bare metal
can be found in :doc:`../bare-metal/ironic-guide`.
Fake Driver
-----------
The fake driver can be used for testing Nova's scaling properties without
requiring access to a large amount of hardware resources. It is covered in
:doc:`nova-fake-driver`.
.. _nova-consoles:
Consoles
========
The console driver may be selected via ``nova_console`` in ``globals.yml``.
Valid options are ``none``, ``novnc`` and ``spice``. Additionally,
serial console support can be enabled by setting
``enable_nova_serialconsole_proxy`` to ``true``.
``spice`` consoles have additional configuration options used by Kolla Ansible:
* nova_spice_html5: configures whether the HTML5 transcoding proxy used by
Horizon is enabled, and defaults to ``true``.
* nova_spice_image_compression: which compression algorithm to use for images
when using the SPICE console type. Defaults to ``auto_glz``.
* nova_spice_jpeg_compression: whether or not to use JPEG compression with
SPICE consoles. Defaults to ``auto``.
* nova_spice_zlib_compression: whether or not to use zlib compression with
SPICE consoles. Defaults to ``auto``.
* nova_spice_playback_compression: whether or not to use compression for video
playback. Defaults to ``true``.
* nova_spice_streaming_mode: what streaming mode to use with SPICE consoles.
Defaults to ``filter``.
Cells
=====
Information on using Nova Cells V2 to scale out can be found in
:doc:`nova-cells-guide`.
Vendordata
==========
Nova supports passing deployer provided data to instances using a
concept known as Vendordata. If a Vendordata file is located in the
following path within the Kolla configuration, Kolla will
automatically use it when the Nova service is deployed or
reconfigured: ``/etc/kolla/config/nova/vendordata.json``.
Failure handling
================
Compute service registration
----------------------------
During deployment, Kolla Ansible waits for Nova compute services to register
themselves. By default, if a compute service does not register itself before
the timeout, that host will be marked as failed in the Ansible run. This
behaviour is useful at scale, where failures are more frequent.
Alternatively, to fail all hosts in a cell when any compute service fails
to register, set ``nova_compute_registration_fatal`` to ``true``.
Managing resource providers via config files
============================================
In the Victoria cycle Nova merged support for managing resource providers
via :nova-doc:`configuration files <admin/managing-resource-providers>`.
Kolla Ansible limits the use of this feature to a single config file per
Nova Compute service, which is defined via Ansible inventory group/host vars.
The reason for doing this is to encourage users to configure each compute
service individually, so that when further resources are added, existing
compute services do not need to be restarted.
For example, a user wanting to configure a compute resource with GPUs for
a specific host may add the following file to host_vars:
.. code-block:: console
[host_vars]$ cat gpu_compute_0001
nova_cell_compute_provider_config:
meta:
schema_version: '1.0'
providers:
- identification:
name: $COMPUTE_NODE
inventories:
additional:
- CUSTOM_GPU:
total: 8
reserved: 0
min_unit: 1
max_unit: 1
step_size: 1
allocation_ratio: 1.0
A similar approach can be used with group vars to cover more than one machine.
Since a badly formatted file will prevent the Nova Compute service from
starting, it should first be validated as described in the
:nova-doc:`documentation <admin/managing-resource-providers>`.
The Nova Compute service can then be reconfigured to apply the change.
To remove the resource provider configuration, it is simplest to leave the
group/host vars in place without specifying any inventory or traits. This will
effectively remove the configuration when the Nova Compute service is restarted.
If you choose to undefine `nova_cell_compute_provider_config` on a host, you must
manually remove the generated config from inside the container, or recreate the
container.
Emulated virtual Trusted Platform Module (vTPM)
===============================================
Nova supports adding an emulated virtual Trusted Platform Module (vTPM) to
instances. This feature is implemented with the SWTPM (Software TPM Emulator)
package. To enable this feature, set ``enable_nova_swtpm`` to ``true``.
Beware of `limitations`__ that come with this solution.
__ https://docs.openstack.org/nova/latest/admin/emulated-tpm.html#limitations
|
