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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
===================
Admin Documentation
===================
The OpenStack Compute service allows you to control an
Infrastructure-as-a-Service (IaaS) cloud computing platform. It gives you
control over instances and networks, and allows you to manage access to the
cloud through users and projects.
Compute does not include virtualization software. Instead, it defines drivers
that interact with underlying virtualization mechanisms that run on your host
operating system, and exposes functionality over a web-based API.
Overview
--------
To effectively administer compute, you must understand how the different
installed nodes interact with each other. Compute can be installed in many
different ways using multiple servers, but generally multiple compute nodes
control the virtual servers and a cloud controller node contains the remaining
Compute services.
The Compute cloud works using a series of daemon processes named ``nova-*``
that exist persistently on the host machine. These binaries can all run on the
same machine or be spread out on multiple boxes in a large deployment. The
responsibilities of services and drivers are:
.. rubric:: Services
:doc:`nova-api-metadata </cli/nova-api-metadata>`
A server daemon that serves the Nova Metadata API.
:doc:`nova-api-os-compute </cli/nova-api-os-compute>`
A server daemon that serves the Nova OpenStack Compute API.
:doc:`nova-api </cli/nova-api>`
A server daemon that serves the metadata and compute APIs in separate
greenthreads.
:doc:`nova-compute </cli/nova-compute>`
Manages virtual machines. Loads a Service object, and exposes the public
methods on ComputeManager through a Remote Procedure Call (RPC).
:doc:`nova-conductor </cli/nova-conductor>`
Provides database-access support for compute nodes (thereby reducing security
risks).
:doc:`nova-scheduler </cli/nova-scheduler>`
Dispatches requests for new virtual machines to the correct node.
:doc:`nova-novncproxy </cli/nova-novncproxy>`
Provides a VNC proxy for browsers, allowing VNC consoles to access virtual
machines.
:doc:`nova-spicehtml5proxy </cli/nova-spicehtml5proxy>`
Provides a SPICE proxy for browsers, allowing SPICE consoles to access
virtual machines.
:doc:`nova-serialproxy </cli/nova-serialproxy>`
Provides a serial console proxy, allowing users to access a virtual machine's
serial console.
The architecture is covered in much greater detail in
:doc:`/admin/architecture`.
.. toctree::
:maxdepth: 2
architecture
.. note::
Some services have drivers that change how the service implements its core
functionality. For example, the ``nova-compute`` service supports drivers
that let you choose which hypervisor type it can use.
Deployment Considerations
-------------------------
There is information you might want to consider before doing your deployment,
especially if it is going to be a larger deployment. For smaller deployments
the defaults from the :doc:`install guide </install/index>` will be sufficient.
* **Compute Driver Features Supported**: While the majority of nova deployments use
libvirt/kvm, you can use nova with other compute drivers. Nova attempts to
provide a unified feature set across these, however, not all features are
implemented on all backends, and not all features are equally well tested.
* :doc:`Feature Support by Use Case </user/feature-classification>`: A view of
what features each driver supports based on what's important to some large
use cases (General Purpose Cloud, NFV Cloud, HPC Cloud).
* :doc:`Feature Support full list </user/support-matrix>`: A detailed dive through
features in each compute driver backend.
* :doc:`Cells v2 configuration </admin/cells>`: For large deployments, cells v2
cells allow sharding of your compute environment. Upfront planning is key to
a successful cells v2 layout.
* :doc:`Availability Zones </admin/availability-zones>`: Availability Zones are
an end-user visible logical abstraction for partitioning a cloud without
knowing the physical infrastructure.
* :placement-doc:`Placement service <>`: Overview of the placement
service, including how it fits in with the rest of nova.
* :doc:`Running nova-api on wsgi </user/wsgi>`: Considerations for using a real
WSGI container instead of the baked-in eventlet web server.
.. toctree::
:maxdepth: 2
cells
aggregates
default-ports
availability-zones
configuration/index
Basic configuration
-------------------
Once you have an OpenStack deployment up and running, you will want to manage
it. The below guides cover everything from creating initial flavor and image to
log management and live migration of instances.
* :doc:`Quotas </admin/quotas>`: Managing project quotas in nova.
* :doc:`Scheduling </admin/scheduling>`: How the scheduler is
configured, and how that will impact where compute instances land in your
environment. If you are seeing unexpected distribution of compute instances
in your hosts, you'll want to dive into this configuration.
* :doc:`Exposing custom metadata to compute instances </admin/vendordata>`: How
and when you might want to extend the basic metadata exposed to compute
instances (either via metadata server or config drive) for your specific
purposes.
.. toctree::
:maxdepth: 2
manage-the-cloud
services
service-groups
manage-logs
root-wrap-reference
ssh-configuration
configuring-migrations
live-migration-usage
secure-live-migration-with-qemu-native-tls
manage-volumes
flavors
admin-password-injection
remote-console-access
scheduling
config-drive
image-caching
metadata-service
quotas
networking
security-groups
security
vendordata
notifications
Advanced configuration
----------------------
OpenStack clouds run on platforms that differ greatly in the capabilities that
they provide. By default, the Compute service seeks to abstract the underlying
hardware that it runs on, rather than exposing specifics about the underlying
host platforms. This abstraction manifests itself in many ways. For example,
rather than exposing the types and topologies of CPUs running on hosts, the
service exposes a number of generic CPUs (virtual CPUs, or vCPUs) and allows
for overcommitting of these. In a similar manner, rather than exposing the
individual types of network devices available on hosts, generic
software-powered network ports are provided. These features are designed to
allow high resource utilization and allows the service to provide a generic
cost-effective and highly scalable cloud upon which to build applications.
This abstraction is beneficial for most workloads. However, there are some
workloads where determinism and per-instance performance are important, if not
vital. In these cases, instances can be expected to deliver near-native
performance. The Compute service provides features to improve individual
instance for these kind of workloads.
.. include:: /common/numa-live-migration-warning.txt
.. toctree::
:maxdepth: 2
pci-passthrough
cpu-topologies
real-time
huge-pages
virtual-gpu
file-backed-memory
ports-with-resource-requests
vdpa
virtual-persistent-memory
emulated-tpm
uefi
secure-boot
sev
managing-resource-providers
compute-node-identification
resource-limits
cpu-models
libvirt-misc
Maintenance
-----------
Once you are running nova, the following information is extremely useful.
* :doc:`Upgrades <upgrades>`: How nova is designed to be upgraded for minimal
service impact, and the order you should do them in.
.. toctree::
:maxdepth: 2
support-compute
evacuate
migration
migrate-instance-with-snapshot
upgrades
node-down
hw-machine-type
hw-emulation-architecture
soft-delete-shadow-tables
|
