doc: Import administration guide
Import all docs from openstack-manuals. Part of bp: doc-migration Change-Id: I28bb8ce1f4a8653f176a554d2e95b4423c437972 Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
This commit is contained in:
chenxing
Sean Dague
parent
01b3ae2e70
commit
575b529118
|
|
@ -0,0 +1,59 @@
|
|||
====================================
|
||||
Injecting the administrator password
|
||||
====================================
|
||||
|
||||
Compute can generate a random administrator (root) password and inject that
|
||||
password into an instance. If this feature is enabled, users can run
|
||||
:command:`ssh` to an instance without an :command:`ssh` keypair. The random
|
||||
password appears in the output of the :command:`openstack server create`
|
||||
command. You can also view and set the admin password from the dashboard.
|
||||
|
||||
.. rubric:: Password injection using the dashboard
|
||||
|
||||
By default, the dashboard will display the ``admin`` password and allow the
|
||||
user to modify it.
|
||||
|
||||
If you do not want to support password injection, disable the password fields
|
||||
by editing the dashboard's ``local_settings.py`` file.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
OPENSTACK_HYPERVISOR_FEATURES = {
|
||||
...
|
||||
'can_set_password': False,
|
||||
}
|
||||
|
||||
.. rubric:: Password injection on libvirt-based hypervisors
|
||||
|
||||
For hypervisors that use the libvirt back end (such as KVM, QEMU, and LXC),
|
||||
admin password injection is disabled by default. To enable it, set this option
|
||||
in ``/etc/nova/nova.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[libvirt]
|
||||
inject_password=true
|
||||
|
||||
When enabled, Compute will modify the password of the admin account by editing
|
||||
the ``/etc/shadow`` file inside the virtual machine instance.
|
||||
|
||||
.. note::
|
||||
|
||||
Users can only use :command:`ssh` to access the instance by using the admin
|
||||
password if the virtual machine image is a Linux distribution, and it has
|
||||
been configured to allow users to use :command:`ssh` as the root user. This
|
||||
is not the case for `Ubuntu cloud images <http://uec-images.ubuntu.com>`_
|
||||
which, by default, does not allow users to use :command:`ssh` to access the
|
||||
root account.
|
||||
|
||||
.. rubric:: Password injection and XenAPI (XenServer/XCP)
|
||||
|
||||
When using the XenAPI hypervisor back end, Compute uses the XenAPI agent to
|
||||
inject passwords into guests. The virtual machine image must be configured with
|
||||
the agent for password injection to work.
|
||||
|
||||
.. rubric:: Password injection and Windows images (all hypervisors)
|
||||
|
||||
For Windows virtual machines, configure the Windows image to retrieve the admin
|
||||
password on boot by installing an agent such as `cloudbase-init
|
||||
<https://cloudbase.it/cloudbase-init>`_.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
======================
|
||||
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.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
pci-passthrough
|
||||
cpu-topologies
|
||||
huge-pages
|
||||
|
|
@ -0,0 +1,361 @@
|
|||
===================
|
||||
System architecture
|
||||
===================
|
||||
|
||||
OpenStack Compute contains several main components.
|
||||
|
||||
- The cloud controller represents the global state and interacts with the
|
||||
other components. The ``API server`` acts as the web services front end for
|
||||
the cloud controller. The ``compute controller`` provides compute server
|
||||
resources and usually also contains the Compute service.
|
||||
|
||||
- The ``object store`` is an optional component that provides storage
|
||||
services; you can also use OpenStack Object Storage instead.
|
||||
|
||||
- An ``auth manager`` provides authentication and authorization services when
|
||||
used with the Compute system; you can also use OpenStack Identity as a
|
||||
separate authentication service instead.
|
||||
|
||||
- A ``volume controller`` provides fast and permanent block-level storage for
|
||||
the compute servers.
|
||||
|
||||
- The ``network controller`` provides virtual networks to enable compute
|
||||
servers to interact with each other and with the public network. You can also
|
||||
use OpenStack Networking instead.
|
||||
|
||||
- The ``scheduler`` is used to select the most suitable compute controller to
|
||||
host an instance.
|
||||
|
||||
Compute uses a messaging-based, ``shared nothing`` architecture. All major
|
||||
components exist on multiple servers, including the compute, volume, and
|
||||
network controllers, and the Object Storage or Image service. The state of the
|
||||
entire system is stored in a database. The cloud controller communicates with
|
||||
the internal object store using HTTP, but it communicates with the scheduler,
|
||||
network controller, and volume controller using Advanced Message Queuing
|
||||
Protocol (AMQP). To avoid blocking a component while waiting for a response,
|
||||
Compute uses asynchronous calls, with a callback that is triggered when a
|
||||
response is received.
|
||||
|
||||
Hypervisors
|
||||
~~~~~~~~~~~
|
||||
|
||||
Compute controls hypervisors through an API server. Selecting the best
|
||||
hypervisor to use can be difficult, and you must take budget, resource
|
||||
constraints, supported features, and required technical specifications into
|
||||
account. However, the majority of OpenStack development is done on systems
|
||||
using KVM and Xen-based hypervisors. For a detailed list of features and
|
||||
support across different hypervisors, see the `Feature Support Matrix
|
||||
<https://docs.openstack.org/developer/nova/support-matrix.html>`_.
|
||||
|
||||
You can also orchestrate clouds using multiple hypervisors in different
|
||||
availability zones. Compute supports the following hypervisors:
|
||||
|
||||
- `Baremetal <https://wiki.openstack.org/wiki/Ironic>`__
|
||||
|
||||
- `Docker <https://www.docker.io>`__
|
||||
|
||||
- `Hyper-V
|
||||
<http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx>`__
|
||||
|
||||
- `Kernel-based Virtual Machine (KVM)
|
||||
<http://www.linux-kvm.org/page/Main_Page>`__
|
||||
|
||||
- `Linux Containers (LXC) <https://linuxcontainers.org/>`__
|
||||
|
||||
- `Quick Emulator (QEMU) <http://wiki.qemu.org/Manual>`__
|
||||
|
||||
- `User Mode Linux (UML) <http://user-mode-linux.sourceforge.net/>`__
|
||||
|
||||
- `VMware vSphere
|
||||
<http://www.vmware.com/products/vsphere-hypervisor/support.html>`__
|
||||
|
||||
- `Xen <http://www.xen.org/support/documentation.html>`__
|
||||
|
||||
For more information about hypervisors, see the `Hypervisors
|
||||
<https://docs.openstack.org/ocata/config-reference/compute/hypervisors.html>`__
|
||||
section in the OpenStack Configuration Reference.
|
||||
|
||||
Projects, users, and roles
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Compute system is designed to be used by different consumers in the form of
|
||||
projects on a shared system, and role-based access assignments. Roles control
|
||||
the actions that a user is allowed to perform.
|
||||
|
||||
Projects are isolated resource containers that form the principal
|
||||
organizational structure within the Compute service. They consist of an
|
||||
individual VLAN, and volumes, instances, images, keys, and users. A user can
|
||||
specify the project by appending ``project_id`` to their access key. If no
|
||||
project is specified in the API request, Compute attempts to use a project with
|
||||
the same ID as the user.
|
||||
|
||||
For projects, you can use quota controls to limit the:
|
||||
|
||||
- Number of volumes that can be launched.
|
||||
|
||||
- Number of processor cores and the amount of RAM that can be allocated.
|
||||
|
||||
- Floating IP addresses assigned to any instance when it launches. This allows
|
||||
instances to have the same publicly accessible IP addresses.
|
||||
|
||||
- Fixed IP addresses assigned to the same instance when it launches. This
|
||||
allows instances to have the same publicly or privately accessible IP
|
||||
addresses.
|
||||
|
||||
Roles control the actions a user is allowed to perform. By default, most
|
||||
actions do not require a particular role, but you can configure them by editing
|
||||
the ``policy.json`` file for user roles. For example, a rule can be defined so
|
||||
that a user must have the ``admin`` role in order to be able to allocate a
|
||||
public IP address.
|
||||
|
||||
A project limits users' access to particular images. Each user is assigned a
|
||||
user name and password. Keypairs granting access to an instance are enabled for
|
||||
each user, but quotas are set, so that each project can control resource
|
||||
consumption across available hardware resources.
|
||||
|
||||
.. note::
|
||||
|
||||
Earlier versions of OpenStack used the term ``tenant`` instead of
|
||||
``project``. Because of this legacy terminology, some command-line tools use
|
||||
``--tenant_id`` where you would normally expect to enter a project ID.
|
||||
|
||||
Block storage
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
OpenStack provides two classes of block storage: ephemeral storage and
|
||||
persistent volume.
|
||||
|
||||
.. rubric:: Ephemeral storage
|
||||
|
||||
Ephemeral storage includes a root ephemeral volume and an additional ephemeral
|
||||
volume.
|
||||
|
||||
The root disk is associated with an instance, and exists only for the life of
|
||||
this very instance. Generally, it is used to store an instance's root file
|
||||
system, persists across the guest operating system reboots, and is removed on
|
||||
an instance deletion. The amount of the root ephemeral volume is defined by the
|
||||
flavor of an instance.
|
||||
|
||||
In addition to the ephemeral root volume, all default types of flavors, except
|
||||
``m1.tiny``, which is the smallest one, provide an additional ephemeral block
|
||||
device sized between 20 and 160 GB (a configurable value to suit an
|
||||
environment). It is represented as a raw block device with no partition table
|
||||
or file system. A cloud-aware operating system can discover, format, and mount
|
||||
such a storage device. OpenStack Compute defines the default file system for
|
||||
different operating systems as Ext4 for Linux distributions, VFAT for non-Linux
|
||||
and non-Windows operating systems, and NTFS for Windows. However, it is
|
||||
possible to specify any other filesystem type by using ``virt_mkfs`` or
|
||||
``default_ephemeral_format`` configuration options.
|
||||
|
||||
.. note::
|
||||
|
||||
For example, the ``cloud-init`` package included into an Ubuntu's stock
|
||||
cloud image, by default, formats this space as an Ext4 file system and
|
||||
mounts it on ``/mnt``. This is a cloud-init feature, and is not an OpenStack
|
||||
mechanism. OpenStack only provisions the raw storage.
|
||||
|
||||
.. rubric:: Persistent volume
|
||||
|
||||
A persistent volume is represented by a persistent virtualized block device
|
||||
independent of any particular instance, and provided by OpenStack Block
|
||||
Storage.
|
||||
|
||||
Only a single configured instance can access a persistent volume. Multiple
|
||||
instances cannot access a persistent volume. This type of configuration
|
||||
requires a traditional network file system to allow multiple instances
|
||||
accessing the persistent volume. It also requires a traditional network file
|
||||
system like NFS, CIFS, or a cluster file system such as GlusterFS. These
|
||||
systems can be built within an OpenStack cluster, or provisioned outside of it,
|
||||
but OpenStack software does not provide these features.
|
||||
|
||||
You can configure a persistent volume as bootable and use it to provide a
|
||||
persistent virtual instance similar to the traditional non-cloud-based
|
||||
virtualization system. It is still possible for the resulting instance to keep
|
||||
ephemeral storage, depending on the flavor selected. In this case, the root
|
||||
file system can be on the persistent volume, and its state is maintained, even
|
||||
if the instance is shut down. For more information about this type of
|
||||
configuration, see `Introduction to the Block Storage service
|
||||
<https://docs.openstack.org/ocata/config-reference/block-storage/block-storage-overview.html>`_
|
||||
in the OpenStack Configuration Reference.
|
||||
|
||||
.. note::
|
||||
|
||||
A persistent volume does not provide concurrent access from multiple
|
||||
instances. That type of configuration requires a traditional network file
|
||||
system like NFS, or CIFS, or a cluster file system such as GlusterFS. These
|
||||
systems can be built within an OpenStack cluster, or provisioned outside of
|
||||
it, but OpenStack software does not provide these features.
|
||||
|
||||
EC2 compatibility API
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. todo:: Does this need to be removed now?
|
||||
|
||||
In addition to the native compute API, OpenStack provides an EC2-compatible
|
||||
API. This API allows EC2 legacy workflows built for EC2 to work with OpenStack.
|
||||
|
||||
.. warning::
|
||||
|
||||
Nova in tree EC2-compatible API is deprecated. The `ec2-api project
|
||||
<https://git.openstack.org/cgit/openstack/ec2-api/>`_ is working to
|
||||
implement the EC2 API.
|
||||
|
||||
You can use numerous third-party tools and language-specific SDKs to interact
|
||||
with OpenStack clouds. You can use both native and compatibility APIs. Some of
|
||||
the more popular third-party tools are:
|
||||
|
||||
Euca2ools
|
||||
A popular open source command-line tool for interacting with the EC2 API.
|
||||
This is convenient for multi-cloud environments where EC2 is the common API,
|
||||
or for transitioning from EC2-based clouds to OpenStack. For more
|
||||
information, see the `Eucalyptus Documentation
|
||||
<http://docs.hpcloud.com/eucalyptus>`__.
|
||||
|
||||
Hybridfox
|
||||
A Firefox browser add-on that provides a graphical interface to many popular
|
||||
public and private cloud technologies, including OpenStack. For more
|
||||
information, see the `hybridfox site
|
||||
<http://code.google.com/p/hybridfox/>`__.
|
||||
|
||||
boto
|
||||
Python library for interacting with Amazon Web Services. You can use this
|
||||
library to access OpenStack through the EC2 compatibility API. For more
|
||||
information, see the `boto project page on GitHub
|
||||
<https://github.com/boto/boto>`__.
|
||||
|
||||
fog
|
||||
A Ruby cloud services library. It provides methods to interact with a large
|
||||
number of cloud and virtualization platforms, including OpenStack. For more
|
||||
information, see the `fog site <https://rubygems.org/gems/fog>`__.
|
||||
|
||||
php-opencloud
|
||||
A PHP SDK designed to work with most OpenStack-based cloud deployments, as
|
||||
well as Rackspace public cloud. For more information, see the `php-opencloud
|
||||
site <http://www.php-opencloud.com>`__.
|
||||
|
||||
Building blocks
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
In OpenStack the base operating system is usually copied from an image stored
|
||||
in the OpenStack Image service. This is the most common case and results in an
|
||||
ephemeral instance that starts from a known template state and loses all
|
||||
accumulated states on virtual machine deletion. It is also possible to put an
|
||||
operating system on a persistent volume in the OpenStack Block Storage volume
|
||||
system. This gives a more traditional persistent system that accumulates states
|
||||
which are preserved on the OpenStack Block Storage volume across the deletion
|
||||
and re-creation of the virtual machine. To get a list of available images on
|
||||
your system, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack image list
|
||||
+--------------------------------------+-----------------------------+--------+
|
||||
| ID | Name | Status |
|
||||
+--------------------------------------+-----------------------------+--------+
|
||||
| aee1d242-730f-431f-88c1-87630c0f07ba | Ubuntu 14.04 cloudimg amd64 | active |
|
||||
| 0b27baa1-0ca6-49a7-b3f4-48388e440245 | Ubuntu 14.10 cloudimg amd64 | active |
|
||||
| df8d56fc-9cea-4dfd-a8d3-28764de3cb08 | jenkins | active |
|
||||
+--------------------------------------+-----------------------------+--------+
|
||||
|
||||
The displayed image attributes are:
|
||||
|
||||
``ID``
|
||||
Automatically generated UUID of the image
|
||||
|
||||
``Name``
|
||||
Free form, human-readable name for image
|
||||
|
||||
``Status``
|
||||
The status of the image. Images marked ``ACTIVE`` are available for use.
|
||||
|
||||
``Server``
|
||||
For images that are created as snapshots of running instances, this is the
|
||||
UUID of the instance the snapshot derives from. For uploaded images, this
|
||||
field is blank.
|
||||
|
||||
Virtual hardware templates are called ``flavors``. By default, these are
|
||||
configurable by admin users, however that behavior can be changed by redefining
|
||||
the access controls for ``compute_extension:flavormanage`` in
|
||||
``/etc/nova/policy.json`` on the ``compute-api`` server.
|
||||
|
||||
For a list of flavors that are available on your system:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor list
|
||||
+-----+-----------+-------+------+-----------+-------+-----------+
|
||||
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is_Public |
|
||||
+-----+-----------+-------+------+-----------+-------+-----------+
|
||||
| 1 | m1.tiny | 512 | 1 | 0 | 1 | True |
|
||||
| 2 | m1.small | 2048 | 20 | 0 | 1 | True |
|
||||
| 3 | m1.medium | 4096 | 40 | 0 | 2 | True |
|
||||
| 4 | m1.large | 8192 | 80 | 0 | 4 | True |
|
||||
| 5 | m1.xlarge | 16384 | 160 | 0 | 8 | True |
|
||||
+-----+-----------+-------+------+-----------+-------+-----------+
|
||||
|
||||
Compute service architecture
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
These basic categories describe the service architecture and information about
|
||||
the cloud controller.
|
||||
|
||||
.. rubric:: API server
|
||||
|
||||
At the heart of the cloud framework is an API server, which makes command and
|
||||
control of the hypervisor, storage, and networking programmatically available
|
||||
to users.
|
||||
|
||||
The API endpoints are basic HTTP web services which handle authentication,
|
||||
authorization, and basic command and control functions using various API
|
||||
interfaces under the Amazon, Rackspace, and related models. This enables API
|
||||
compatibility with multiple existing tool sets created for interaction with
|
||||
offerings from other vendors. This broad compatibility prevents vendor lock-in.
|
||||
|
||||
.. rubric:: Message queue
|
||||
|
||||
A messaging queue brokers the interaction between compute nodes (processing),
|
||||
the networking controllers (software which controls network infrastructure),
|
||||
API endpoints, the scheduler (determines which physical hardware to allocate to
|
||||
a virtual resource), and similar components. Communication to and from the
|
||||
cloud controller is handled by HTTP requests through multiple API endpoints.
|
||||
|
||||
A typical message passing event begins with the API server receiving a request
|
||||
from a user. The API server authenticates the user and ensures that they are
|
||||
permitted to issue the subject command. The availability of objects implicated
|
||||
in the request is evaluated and, if available, the request is routed to the
|
||||
queuing engine for the relevant workers. Workers continually listen to the
|
||||
queue based on their role, and occasionally their type host name. When an
|
||||
applicable work request arrives on the queue, the worker takes assignment of
|
||||
the task and begins executing it. Upon completion, a response is dispatched to
|
||||
the queue which is received by the API server and relayed to the originating
|
||||
user. Database entries are queried, added, or removed as necessary during the
|
||||
process.
|
||||
|
||||
.. rubric:: Compute worker
|
||||
|
||||
Compute workers manage computing instances on host machines. The API dispatches
|
||||
commands to compute workers to complete these tasks:
|
||||
|
||||
- Run instances
|
||||
|
||||
- Delete instances (Terminate instances)
|
||||
|
||||
- Reboot instances
|
||||
|
||||
- Attach volumes
|
||||
|
||||
- Detach volumes
|
||||
|
||||
- Get console output
|
||||
|
||||
.. rubric:: Network Controller
|
||||
|
||||
The Network Controller manages the networking resources on host machines. The
|
||||
API server dispatches commands through the message queue, which are
|
||||
subsequently processed by Network Controllers. Specific operations include:
|
||||
|
||||
- Allocating fixed IP addresses
|
||||
|
||||
- Configuring VLANs for projects
|
||||
|
||||
- Configuring networks for compute nodes
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
=============================================
|
||||
Show usage statistics for hosts and instances
|
||||
=============================================
|
||||
|
||||
You can show basic statistics on resource usage for hosts and instances.
|
||||
|
||||
.. note::
|
||||
|
||||
For more sophisticated monitoring, see the
|
||||
`ceilometer <https://launchpad.net/ceilometer>`__ project. You can
|
||||
also use tools, such as `Ganglia <http://ganglia.info/>`__ or
|
||||
`Graphite <http://graphite.wikidot.com/>`__, to gather more detailed
|
||||
data.
|
||||
|
||||
Show host usage statistics
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following examples show the host usage statistics for a host called
|
||||
``devstack``.
|
||||
|
||||
* List the hosts and the nova-related services that run on them:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack host list
|
||||
+-----------+-------------+----------+
|
||||
| Host Name | Service | Zone |
|
||||
+-----------+-------------+----------+
|
||||
| devstack | conductor | internal |
|
||||
| devstack | compute | nova |
|
||||
| devstack | cert | internal |
|
||||
| devstack | network | internal |
|
||||
| devstack | scheduler | internal |
|
||||
| devstack | consoleauth | internal |
|
||||
+-----------+-------------+----------+
|
||||
|
||||
* Get a summary of resource usage of all of the instances running on the host:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack host show devstack
|
||||
+----------+----------------------------------+-----+-----------+---------+
|
||||
| Host | Project | CPU | MEMORY MB | DISK GB |
|
||||
+----------+----------------------------------+-----+-----------+---------+
|
||||
| devstack | (total) | 2 | 4003 | 157 |
|
||||
| devstack | (used_now) | 3 | 5120 | 40 |
|
||||
| devstack | (used_max) | 3 | 4608 | 40 |
|
||||
| devstack | b70d90d65e464582b6b2161cf3603ced | 1 | 512 | 0 |
|
||||
| devstack | 66265572db174a7aa66eba661f58eb9e | 2 | 4096 | 40 |
|
||||
+----------+----------------------------------+-----+-----------+---------+
|
||||
|
||||
The ``CPU`` column shows the sum of the virtual CPUs for instances running on
|
||||
the host.
|
||||
|
||||
The ``MEMORY MB`` column shows the sum of the memory (in MB) allocated to the
|
||||
instances that run on the host.
|
||||
|
||||
The ``DISK GB`` column shows the sum of the root and ephemeral disk sizes (in
|
||||
GB) of the instances that run on the host.
|
||||
|
||||
The row that has the value ``used_now`` in the ``PROJECT`` column shows the
|
||||
sum of the resources allocated to the instances that run on the host, plus
|
||||
the resources allocated to the virtual machine of the host itself.
|
||||
|
||||
The row that has the value ``used_max`` in the ``PROJECT`` column shows the
|
||||
sum of the resources allocated to the instances that run on the host.
|
||||
|
||||
.. note::
|
||||
|
||||
These values are computed by using information about the flavors of the
|
||||
instances that run on the hosts. This command does not query the CPU
|
||||
usage, memory usage, or hard disk usage of the physical host.
|
||||
|
||||
Show instance usage statistics
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* Get CPU, memory, I/O, and network statistics for an instance.
|
||||
|
||||
#. List instances:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server list
|
||||
+----------+----------------------+--------+------------+-------------+------------------+------------+
|
||||
| ID | Name | Status | Task State | Power State | Networks | Image Name |
|
||||
+----------+----------------------+--------+------------+-------------+------------------+------------+
|
||||
| 84c6e... | myCirrosServer | ACTIVE | None | Running | private=10.0.0.3 | cirros |
|
||||
| 8a995... | myInstanceFromVolume | ACTIVE | None | Running | private=10.0.0.4 | ubuntu |
|
||||
+----------+----------------------+--------+------------+-------------+------------------+------------+
|
||||
|
||||
#. Get diagnostic statistics:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova diagnostics myCirrosServer
|
||||
+---------------------------+--------+
|
||||
| Property | Value |
|
||||
+---------------------------+--------+
|
||||
| memory | 524288 |
|
||||
| memory-actual | 524288 |
|
||||
| memory-rss | 6444 |
|
||||
| tap1fec8fb8-7a_rx | 22137 |
|
||||
| tap1fec8fb8-7a_rx_drop | 0 |
|
||||
| tap1fec8fb8-7a_rx_errors | 0 |
|
||||
| tap1fec8fb8-7a_rx_packets | 166 |
|
||||
| tap1fec8fb8-7a_tx | 18032 |
|
||||
| tap1fec8fb8-7a_tx_drop | 0 |
|
||||
| tap1fec8fb8-7a_tx_errors | 0 |
|
||||
| tap1fec8fb8-7a_tx_packets | 130 |
|
||||
| vda_errors | -1 |
|
||||
| vda_read | 2048 |
|
||||
| vda_read_req | 2 |
|
||||
| vda_write | 182272 |
|
||||
| vda_write_req | 74 |
|
||||
+---------------------------+--------+
|
||||
|
||||
* Get summary statistics for each project:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack usage list
|
||||
Usage from 2013-06-25 to 2013-07-24:
|
||||
+---------+---------+--------------+-----------+---------------+
|
||||
| Project | Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours |
|
||||
+---------+---------+--------------+-----------+---------------+
|
||||
| demo | 1 | 344064.44 | 672.00 | 0.00 |
|
||||
| stack | 3 | 671626.76 | 327.94 | 6558.86 |
|
||||
+---------+---------+--------------+-----------+---------------+
|
||||
|
|
@ -0,0 +1,423 @@
|
|||
.. _section_configuring-compute-migrations:
|
||||
|
||||
=========================
|
||||
Configure live migrations
|
||||
=========================
|
||||
|
||||
Migration enables an administrator to move a virtual machine instance from one
|
||||
compute host to another. A typical scenario is planned maintenance on the
|
||||
source host, but migration can also be useful to redistribute the load when
|
||||
many VM instances are running on a specific physical machine.
|
||||
|
||||
This document covers live migrations using the
|
||||
:ref:`configuring-migrations-kvm-libvirt` and
|
||||
:ref:`configuring-migrations-xenserver` hypervisors.
|
||||
|
||||
.. :ref:`_configuring-migrations-kvm-libvirt`
|
||||
.. :ref:`_configuring-migrations-xenserver`
|
||||
|
||||
.. note::
|
||||
|
||||
Not all Compute service hypervisor drivers support live-migration, or
|
||||
support all live-migration features.
|
||||
|
||||
Consult the `Hypervisor Support Matrix
|
||||
<https://docs.openstack.org/developer/nova/support-matrix.html>`_ to
|
||||
determine which hypervisors support live-migration.
|
||||
|
||||
See the `Hypervisor configuration pages
|
||||
<https://docs.openstack.org/ocata/config-reference/compute/hypervisors.html>`_
|
||||
for details on hypervisor-specific configuration settings.
|
||||
|
||||
The migration types are:
|
||||
|
||||
- **Non-live migration**, also known as cold migration or simply migration.
|
||||
|
||||
The instance is shut down, then moved to another hypervisor and restarted.
|
||||
The instance recognizes that it was rebooted, and the application running on
|
||||
the instance is disrupted.
|
||||
|
||||
This section does not cover cold migration.
|
||||
|
||||
- **Live migration**
|
||||
|
||||
The instance keeps running throughout the migration. This is useful when it
|
||||
is not possible or desirable to stop the application running on the instance.
|
||||
|
||||
Live migrations can be classified further by the way they treat instance
|
||||
storage:
|
||||
|
||||
- **Shared storage-based live migration**. The instance has ephemeral disks
|
||||
that are located on storage shared between the source and destination
|
||||
hosts.
|
||||
|
||||
- **Block live migration**, or simply block migration. The instance has
|
||||
ephemeral disks that are not shared between the source and destination
|
||||
hosts. Block migration is incompatible with read-only devices such as
|
||||
CD-ROMs and `Configuration Drive (config\_drive)
|
||||
<https://docs.openstack.org/user-guide/cli-config-drive.html>`_.
|
||||
|
||||
- **Volume-backed live migration**. Instances use volumes rather than
|
||||
ephemeral disks.
|
||||
|
||||
Block live migration requires copying disks from the source to the
|
||||
destination host. It takes more time and puts more load on the network.
|
||||
Shared-storage and volume-backed live migration does not copy disks.
|
||||
|
||||
.. note::
|
||||
|
||||
In a multi-cell cloud, instances can be live migrated to a
|
||||
different host in the same cell, but not across cells.
|
||||
|
||||
The following sections describe how to configure your hosts for live migrations
|
||||
using the KVM and XenServer hypervisors.
|
||||
|
||||
.. _configuring-migrations-kvm-libvirt:
|
||||
|
||||
KVM-libvirt
|
||||
~~~~~~~~~~~
|
||||
|
||||
.. :ref:`_configuring-migrations-kvm-general`
|
||||
.. :ref:`_configuring-migrations-kvm-block-and-volume-migration`
|
||||
.. :ref:`_configuring-migrations-kvm-shared-storage`
|
||||
|
||||
.. _configuring-migrations-kvm-general:
|
||||
|
||||
General configuration
|
||||
---------------------
|
||||
|
||||
To enable any type of live migration, configure the compute hosts according to
|
||||
the instructions below:
|
||||
|
||||
#. Set the following parameters in ``nova.conf`` on all compute hosts:
|
||||
|
||||
- ``vncserver_listen=0.0.0.0``
|
||||
|
||||
You must not make the VNC server listen to the IP address of its compute
|
||||
host, since that addresses changes when the instance is migrated.
|
||||
|
||||
.. important::
|
||||
|
||||
Since this setting allows VNC clients from any IP address to connect to
|
||||
instance consoles, you must take additional measures like secure
|
||||
networks or firewalls to prevent potential attackers from gaining
|
||||
access to instances.
|
||||
|
||||
- ``instances_path`` must have the same value for all compute hosts. In
|
||||
this guide, the value ``/var/lib/nova/instances`` is assumed.
|
||||
|
||||
#. Ensure that name resolution on all compute hosts is identical, so that they
|
||||
can connect each other through their hostnames.
|
||||
|
||||
If you use ``/etc/hosts`` for name resolution and enable SELinux, ensure
|
||||
that ``/etc/hosts`` has the correct SELinux context:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# restorecon /etc/hosts
|
||||
|
||||
#. Enable password-less SSH so that root on one compute host can log on to any
|
||||
other compute host without providing a password. The ``libvirtd`` daemon,
|
||||
which runs as root, uses the SSH protocol to copy the instance to the
|
||||
destination and can't know the passwords of all compute hosts.
|
||||
|
||||
You may, for example, compile root's public SSH keys on all compute hosts
|
||||
into an ``authorized_keys`` file and deploy that file to the compute hosts.
|
||||
|
||||
#. Configure the firewalls to allow libvirt to communicate between compute
|
||||
hosts.
|
||||
|
||||
By default, libvirt uses the TCP port range from 49152 to 49261 for copying
|
||||
memory and disk contents. Compute hosts must accept connections in this
|
||||
range.
|
||||
|
||||
For information about ports used by libvirt, see the `libvirt documentation
|
||||
<http://libvirt.org/remote.html#Remote_libvirtd_configuration>`_.
|
||||
|
||||
.. important::
|
||||
|
||||
Be mindful of the security risks introduced by opening ports.
|
||||
|
||||
.. _configuring-migrations-kvm-block-and-volume-migration:
|
||||
|
||||
Block migration, volume-based live migration
|
||||
--------------------------------------------
|
||||
|
||||
No additional configuration is required for block migration and volume-backed
|
||||
live migration.
|
||||
|
||||
Be aware that block migration adds load to the network and storage subsystems.
|
||||
|
||||
.. _configuring-migrations-kvm-shared-storage:
|
||||
|
||||
Shared storage
|
||||
--------------
|
||||
|
||||
Compute hosts have many options for sharing storage, for example NFS, shared
|
||||
disk array LUNs, Ceph or GlusterFS.
|
||||
|
||||
The next steps show how a regular Linux system might be configured as an NFS v4
|
||||
server for live migration. For detailed information and alternative ways to
|
||||
configure NFS on Linux, see instructions for `Ubuntu
|
||||
<https://help.ubuntu.com/community/SettingUpNFSHowTo>`_, `RHEL and derivatives
|
||||
<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/nfs-serverconfig.html>`_
|
||||
or `SLES and OpenSUSE
|
||||
<https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_nfs_configuring-nfs-server.html>`_.
|
||||
|
||||
#. Ensure that UID and GID of the nova user are identical on the compute hosts
|
||||
and the NFS server.
|
||||
|
||||
#. Create a directory with enough disk space for all instances in the cloud,
|
||||
owned by user nova. In this guide, we assume ``/var/lib/nova/instances``.
|
||||
|
||||
#. Set the execute/search bit on the ``instances`` directory:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ chmod o+x /var/lib/nova/instances
|
||||
|
||||
This allows qemu to access the ``instances`` directory tree.
|
||||
|
||||
#. Export ``/var/lib/nova/instances`` to the compute hosts. For example, add
|
||||
the following line to ``/etc/exports``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
/var/lib/nova/instances *(rw,sync,fsid=0,no_root_squash)
|
||||
|
||||
The asterisk permits access to any NFS client. The option ``fsid=0`` exports
|
||||
the instances directory as the NFS root.
|
||||
|
||||
After setting up the NFS server, mount the remote filesystem on all compute
|
||||
hosts.
|
||||
|
||||
#. Assuming the NFS server's hostname is ``nfs-server``, add this line to
|
||||
``/etc/fstab`` to mount the NFS root:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
nfs-server:/ /var/lib/nova/instances nfs4 defaults 0 0
|
||||
|
||||
#. Test NFS by mounting the instances directory and check access permissions
|
||||
for the nova user:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo mount -a -v
|
||||
$ ls -ld /var/lib/nova/instances/
|
||||
drwxr-xr-x. 2 nova nova 6 Mar 14 21:30 /var/lib/nova/instances/
|
||||
|
||||
.. _configuring-migrations-kvm-advanced:
|
||||
|
||||
Advanced configuration for KVM and QEMU
|
||||
---------------------------------------
|
||||
|
||||
Live migration copies the instance's memory from the source to the destination
|
||||
compute host. After a memory page has been copied, the instance may write to it
|
||||
again, so that it has to be copied again. Instances that frequently write to
|
||||
different memory pages can overwhelm the memory copy process and prevent the
|
||||
live migration from completing.
|
||||
|
||||
This section covers configuration settings that can help live migration of
|
||||
memory-intensive instances succeed.
|
||||
|
||||
#. **Live migration completion timeout**
|
||||
|
||||
The Compute service aborts a migration when it has been running for too
|
||||
long. The timeout is calculated based on the instance size, which is the
|
||||
instance's memory size in GiB. In the case of block migration, the size of
|
||||
ephemeral storage in GiB is added.
|
||||
|
||||
The timeout in seconds is the instance size multiplied by the configurable
|
||||
parameter ``live_migration_completion_timeout``, whose default is 800. For
|
||||
example, shared-storage live migration of an instance with 8GiB memory will
|
||||
time out after 6400 seconds.
|
||||
|
||||
#. **Live migration progress timeout**
|
||||
|
||||
The Compute service also aborts a live migration when it detects that memory
|
||||
copy is not making progress for a certain time. You can set this time, in
|
||||
seconds, through the configurable parameter
|
||||
``live_migration_progress_timeout``.
|
||||
|
||||
In Ocata, the default value of ``live_migration_progress_timeout`` is 0,
|
||||
which disables progress timeouts. You should not change this value, since
|
||||
the algorithm that detects memory copy progress has been determined to be
|
||||
unreliable. It may be re-enabled in future releases.
|
||||
|
||||
#. **Instance downtime**
|
||||
|
||||
Near the end of the memory copy, the instance is paused for a short time so
|
||||
that the remaining few pages can be copied without interference from
|
||||
instance memory writes. The Compute service initializes this time to a small
|
||||
value that depends on the instance size, typically around 50 milliseconds.
|
||||
When it notices that the memory copy does not make sufficient progress, it
|
||||
increases the time gradually.
|
||||
|
||||
You can influence the instance downtime algorithm with the help of three
|
||||
configuration variables on the compute hosts:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
live_migration_downtime = 500
|
||||
live_migration_downtime_steps = 10
|
||||
live_migration_downtime_delay = 75
|
||||
|
||||
``live_migration_downtime`` sets the maximum permitted downtime for a live
|
||||
migration, in *milliseconds*. The default is 500.
|
||||
|
||||
``live_migration_downtime_steps`` sets the total number of adjustment steps
|
||||
until ``live_migration_downtime`` is reached. The default is 10 steps.
|
||||
|
||||
``live_migration_downtime_delay`` sets the time interval between two
|
||||
adjustment steps in *seconds*. The default is 75.
|
||||
|
||||
#. **Auto-convergence**
|
||||
|
||||
One strategy for a successful live migration of a memory-intensive instance
|
||||
is slowing the instance down. This is called auto-convergence. Both libvirt
|
||||
and QEMU implement this feature by automatically throttling the instance's
|
||||
CPU when memory copy delays are detected.
|
||||
|
||||
Auto-convergence is disabled by default. You can enable it by setting
|
||||
``live_migration_permit_auto_convergence=true``.
|
||||
|
||||
.. caution::
|
||||
|
||||
Before enabling auto-convergence, make sure that the instance's
|
||||
application tolerates a slow-down.
|
||||
|
||||
Be aware that auto-convergence does not guarantee live migration success.
|
||||
|
||||
#. **Post-copy**
|
||||
|
||||
Live migration of a memory-intensive instance is certain to succeed when you
|
||||
enable post-copy. This feature, implemented by libvirt and QEMU, activates
|
||||
the virtual machine on the destination host before all of its memory has
|
||||
been copied. When the virtual machine accesses a page that is missing on
|
||||
the destination host, the resulting page fault is resolved by copying the
|
||||
page from the source host.
|
||||
|
||||
Post-copy is disabled by default. You can enable it by setting
|
||||
``live_migration_permit_post_copy=true``.
|
||||
|
||||
When you enable both auto-convergence and post-copy, auto-convergence
|
||||
remains disabled.
|
||||
|
||||
.. caution::
|
||||
|
||||
The page faults introduced by post-copy can slow the instance down.
|
||||
|
||||
When the network connection between source and destination host is
|
||||
interrupted, page faults cannot be resolved anymore and the instance is
|
||||
rebooted.
|
||||
|
||||
.. TODO Bernd: I *believe* that it is certain to succeed,
|
||||
.. but perhaps I am missing something.
|
||||
|
||||
The full list of live migration configuration parameters is documented in the
|
||||
`OpenStack Configuration Reference Guide
|
||||
<https://docs.openstack.org/ocata/config-reference/compute/config-options.html>`_
|
||||
|
||||
.. _configuring-migrations-xenserver:
|
||||
|
||||
XenServer
|
||||
~~~~~~~~~
|
||||
|
||||
.. :ref:Shared Storage
|
||||
.. :ref:Block migration
|
||||
|
||||
.. _configuring-migrations-xenserver-shared-storage:
|
||||
|
||||
Shared storage
|
||||
--------------
|
||||
|
||||
**Prerequisites**
|
||||
|
||||
- **Compatible XenServer hypervisors**.
|
||||
|
||||
For more information, see the `Requirements for Creating Resource Pools
|
||||
<http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#pooling_homogeneity_requirements>`_
|
||||
section of the XenServer Administrator's Guide.
|
||||
|
||||
- **Shared storage**.
|
||||
|
||||
An NFS export, visible to all XenServer hosts.
|
||||
|
||||
.. note::
|
||||
|
||||
For the supported NFS versions, see the `NFS VHD
|
||||
<http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#id1002701>`_
|
||||
section of the XenServer Administrator's Guide.
|
||||
|
||||
To use shared storage live migration with XenServer hypervisors, the hosts must
|
||||
be joined to a XenServer pool. To create that pool, a host aggregate must be
|
||||
created with specific metadata. This metadata is used by the XAPI plug-ins to
|
||||
establish the pool.
|
||||
|
||||
.. rubric:: Using shared storage live migrations with XenServer Hypervisors
|
||||
|
||||
#. Add an NFS VHD storage to your master XenServer, and set it as the default
|
||||
storage repository. For more information, see NFS VHD in the XenServer
|
||||
Administrator's Guide.
|
||||
|
||||
#. Configure all compute nodes to use the default storage repository (``sr``)
|
||||
for pool operations. Add this line to your ``nova.conf`` configuration files
|
||||
on all compute nodes:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
sr_matching_filter=default-sr:true
|
||||
|
||||
#. Create a host aggregate. This command creates the aggregate, and then
|
||||
displays a table that contains the ID of the new aggregate
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack aggregate create --zone AVAILABILITY_ZONE POOL_NAME
|
||||
|
||||
Add metadata to the aggregate, to mark it as a hypervisor pool
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack aggregate set --property hypervisor_pool=true AGGREGATE_ID
|
||||
|
||||
$ openstack aggregate set --property operational_state=created AGGREGATE_ID
|
||||
|
||||
Make the first compute node part of that aggregate
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack aggregate add host AGGREGATE_ID MASTER_COMPUTE_NAME
|
||||
|
||||
The host is now part of a XenServer pool.
|
||||
|
||||
#. Add hosts to the pool
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack aggregate add host AGGREGATE_ID COMPUTE_HOST_NAME
|
||||
|
||||
.. note::
|
||||
|
||||
The added compute node and the host will shut down to join the host to
|
||||
the XenServer pool. The operation will fail if any server other than the
|
||||
compute node is running or suspended on the host.
|
||||
|
||||
.. _configuring-migrations-xenserver-block-migration:
|
||||
|
||||
Block migration
|
||||
---------------
|
||||
|
||||
- **Compatible XenServer hypervisors**.
|
||||
|
||||
The hypervisors must support the Storage XenMotion feature. See your
|
||||
XenServer manual to make sure your edition has this feature.
|
||||
|
||||
.. note::
|
||||
|
||||
- To use block migration, you must use the ``--block-migrate`` parameter
|
||||
with the live migration command.
|
||||
|
||||
- Block migration works only with EXT local storage storage repositories,
|
||||
and the server must not have any volumes attached.
|
||||
|
|
@ -0,0 +1,365 @@
|
|||
==============
|
||||
CPU topologies
|
||||
==============
|
||||
|
||||
The NUMA topology and CPU pinning features in OpenStack provide high-level
|
||||
control over how instances run on hypervisor CPUs and the topology of virtual
|
||||
CPUs available to instances. These features help minimize latency and maximize
|
||||
performance.
|
||||
|
||||
SMP, NUMA, and SMT
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Symmetric multiprocessing (SMP)
|
||||
SMP is a design found in many modern multi-core systems. In an SMP system,
|
||||
there are two or more CPUs and these CPUs are connected by some interconnect.
|
||||
This provides CPUs with equal access to system resources like memory and
|
||||
input/output ports.
|
||||
|
||||
Non-uniform memory access (NUMA)
|
||||
NUMA is a derivative of the SMP design that is found in many multi-socket
|
||||
systems. In a NUMA system, system memory is divided into cells or nodes that
|
||||
are associated with particular CPUs. Requests for memory on other nodes are
|
||||
possible through an interconnect bus. However, bandwidth across this shared
|
||||
bus is limited. As a result, competition for this resource can incur
|
||||
performance penalties.
|
||||
|
||||
Simultaneous Multi-Threading (SMT)
|
||||
SMT is a design complementary to SMP. Whereas CPUs in SMP systems share a bus
|
||||
and some memory, CPUs in SMT systems share many more components. CPUs that
|
||||
share components are known as thread siblings. All CPUs appear as usable
|
||||
CPUs on the system and can execute workloads in parallel. However, as with
|
||||
NUMA, threads compete for shared resources.
|
||||
|
||||
In OpenStack, SMP CPUs are known as *cores*, NUMA cells or nodes are known as
|
||||
*sockets*, and SMT CPUs are known as *threads*. For example, a quad-socket,
|
||||
eight core system with Hyper-Threading would have four sockets, eight cores per
|
||||
socket and two threads per core, for a total of 64 CPUs.
|
||||
|
||||
Configuring compute nodes for instances with NUMA placement policies
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Hyper-V is configured by default to allow instances to span multiple NUMA
|
||||
nodes, regardless if the instances have been configured to only span N NUMA
|
||||
nodes. This behaviour allows Hyper-V instances to have up to 64 vCPUs and 1 TB
|
||||
of memory.
|
||||
|
||||
Checking NUMA spanning can easily be done by running this following powershell
|
||||
command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
(Get-VMHost).NumaSpanningEnabled
|
||||
|
||||
In order to disable this behaviour, the host will have to be configured to
|
||||
disable NUMA spanning. This can be done by executing these following
|
||||
powershell commands:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Set-VMHost -NumaSpanningEnabled $false
|
||||
Restart-Service vmms
|
||||
|
||||
In order to restore this behaviour, execute these powershell commands:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Set-VMHost -NumaSpanningEnabled $true
|
||||
Restart-Service vmms
|
||||
|
||||
The ``vmms`` service (Virtual Machine Management Service) is responsible for
|
||||
managing the Hyper-V VMs. The VMs will still run while the service is down
|
||||
or restarting, but they will not be manageable by the ``nova-compute``
|
||||
service. In order for the effects of the Host NUMA spanning configuration
|
||||
to take effect, the VMs will have to be restarted.
|
||||
|
||||
Hyper-V does not allow instances with a NUMA topology to have dynamic
|
||||
memory allocation turned on. The Hyper-V driver will ignore the configured
|
||||
``dynamic_memory_ratio`` from the given ``nova.conf`` file when spawning
|
||||
instances with a NUMA topology.
|
||||
|
||||
Customizing instance NUMA placement policies
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. important::
|
||||
|
||||
The functionality described below is currently only supported by the
|
||||
libvirt/KVM and Hyper-V driver.
|
||||
|
||||
When running workloads on NUMA hosts, it is important that the vCPUs executing
|
||||
processes are on the same NUMA node as the memory used by these processes.
|
||||
This ensures all memory accesses are local to the node and thus do not consume
|
||||
the limited cross-node memory bandwidth, adding latency to memory accesses.
|
||||
Similarly, large pages are assigned from memory and benefit from the same
|
||||
performance improvements as memory allocated using standard pages. Thus, they
|
||||
also should be local. Finally, PCI devices are directly associated with
|
||||
specific NUMA nodes for the purposes of DMA. Instances that use PCI or SR-IOV
|
||||
devices should be placed on the NUMA node associated with these devices.
|
||||
|
||||
By default, an instance floats across all NUMA nodes on a host. NUMA awareness
|
||||
can be enabled implicitly through the use of huge pages or pinned CPUs or
|
||||
explicitly through the use of flavor extra specs or image metadata. In all
|
||||
cases, the ``NUMATopologyFilter`` filter must be enabled. Details on this
|
||||
filter are provided in `Scheduling`_ configuration guide.
|
||||
|
||||
.. caution::
|
||||
|
||||
The NUMA node(s) used are normally chosen at random. However, if a PCI
|
||||
passthrough or SR-IOV device is attached to the instance, then the NUMA
|
||||
node that the device is associated with will be used. This can provide
|
||||
important performance improvements. However, booting a large number of
|
||||
similar instances can result in unbalanced NUMA node usage. Care should
|
||||
be taken to mitigate this issue. See this `discussion`_ for more details.
|
||||
|
||||
.. caution::
|
||||
|
||||
Inadequate per-node resources will result in scheduling failures. Resources
|
||||
that are specific to a node include not only CPUs and memory, but also PCI
|
||||
and SR-IOV resources. It is not possible to use multiple resources from
|
||||
different nodes without requesting a multi-node layout. As such, it may be
|
||||
necessary to ensure PCI or SR-IOV resources are associated with the same
|
||||
NUMA node or force a multi-node layout.
|
||||
|
||||
When used, NUMA awareness allows the operating system of the instance to
|
||||
intelligently schedule the workloads that it runs and minimize cross-node
|
||||
memory bandwidth. To restrict an instance's vCPUs to a single host NUMA node,
|
||||
run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:numa_nodes=1
|
||||
|
||||
Some workloads have very demanding requirements for memory access latency or
|
||||
bandwidth that exceed the memory bandwidth available from a single NUMA node.
|
||||
For such workloads, it is beneficial to spread the instance across multiple
|
||||
host NUMA nodes, even if the instance's RAM/vCPUs could theoretically fit on a
|
||||
single NUMA node. To force an instance's vCPUs to spread across two host NUMA
|
||||
nodes, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:numa_nodes=2
|
||||
|
||||
The allocation of instances vCPUs and memory from different host NUMA nodes can
|
||||
be configured. This allows for asymmetric allocation of vCPUs and memory, which
|
||||
can be important for some workloads. To spread the 6 vCPUs and 6 GB of memory
|
||||
of an instance across two NUMA nodes and create an asymmetric 1:2 vCPU and
|
||||
memory mapping between the two nodes, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:numa_nodes=2
|
||||
$ openstack flavor set m1.large \ # configure guest node 0
|
||||
--property hw:numa_cpus.0=0,1 \
|
||||
--property hw:numa_mem.0=2048
|
||||
$ openstack flavor set m1.large \ # configure guest node 1
|
||||
--property hw:numa_cpus.1=2,3,4,5 \
|
||||
--property hw:numa_mem.1=4096
|
||||
|
||||
.. note::
|
||||
|
||||
Hyper-V does not support asymmetric NUMA topologies, and the Hyper-V
|
||||
driver will not spawn instances with such topologies.
|
||||
|
||||
For more information about the syntax for ``hw:numa_nodes``, ``hw:numa_cpus.N``
|
||||
and ``hw:num_mem.N``, refer to the `Flavors`_ guide.
|
||||
|
||||
Customizing instance CPU pinning policies
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. important::
|
||||
|
||||
The functionality described below is currently only supported by the
|
||||
libvirt/KVM driver. Hyper-V does not support CPU pinning.
|
||||
|
||||
By default, instance vCPU processes are not assigned to any particular host
|
||||
CPU, instead, they float across host CPUs like any other process. This allows
|
||||
for features like overcommitting of CPUs. In heavily contended systems, this
|
||||
provides optimal system performance at the expense of performance and latency
|
||||
for individual instances.
|
||||
|
||||
Some workloads require real-time or near real-time behavior, which is not
|
||||
possible with the latency introduced by the default CPU policy. For such
|
||||
workloads, it is beneficial to control which host CPUs are bound to an
|
||||
instance's vCPUs. This process is known as pinning. No instance with pinned
|
||||
CPUs can use the CPUs of another pinned instance, thus preventing resource
|
||||
contention between instances. To configure a flavor to use pinned vCPUs, a
|
||||
use a dedicated CPU policy. To force this, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:cpu_policy=dedicated
|
||||
|
||||
.. caution::
|
||||
|
||||
Host aggregates should be used to separate pinned instances from unpinned
|
||||
instances as the latter will not respect the resourcing requirements of
|
||||
the former.
|
||||
|
||||
When running workloads on SMT hosts, it is important to be aware of the impact
|
||||
that thread siblings can have. Thread siblings share a number of components
|
||||
and contention on these components can impact performance. To configure how
|
||||
to use threads, a CPU thread policy should be specified. For workloads where
|
||||
sharing benefits performance, use thread siblings. To force this, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large \
|
||||
--property hw:cpu_policy=dedicated \
|
||||
--property hw:cpu_thread_policy=require
|
||||
|
||||
For other workloads where performance is impacted by contention for resources,
|
||||
use non-thread siblings or non-SMT hosts. To force this, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large \
|
||||
--property hw:cpu_policy=dedicated \
|
||||
--property hw:cpu_thread_policy=isolate
|
||||
|
||||
Finally, for workloads where performance is minimally impacted, use thread
|
||||
siblings if available. This is the default, but it can be set explicitly:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large \
|
||||
--property hw:cpu_policy=dedicated \
|
||||
--property hw:cpu_thread_policy=prefer
|
||||
|
||||
For more information about the syntax for ``hw:cpu_policy`` and
|
||||
``hw:cpu_thread_policy``, refer to the `Flavors`_ guide.
|
||||
|
||||
Applications are frequently packaged as images. For applications that require
|
||||
real-time or near real-time behavior, configure image metadata to ensure
|
||||
created instances are always pinned regardless of flavor. To configure an
|
||||
image to use pinned vCPUs and avoid thread siblings, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack image set [IMAGE_ID] \
|
||||
--property hw_cpu_policy=dedicated \
|
||||
--property hw_cpu_thread_policy=isolate
|
||||
|
||||
If the flavor specifies a CPU policy of ``dedicated`` then that policy will be
|
||||
used. If the flavor explicitly specifies a CPU policy of ``shared`` and the
|
||||
image specifies no policy or a policy of ``shared`` then the ``shared`` policy
|
||||
will be used, but if the image specifies a policy of ``dedicated`` an exception
|
||||
will be raised. By setting a ``shared`` policy through flavor extra-specs,
|
||||
administrators can prevent users configuring CPU policies in images and
|
||||
impacting resource utilization. To configure this policy, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:cpu_policy=shared
|
||||
|
||||
If the flavor does not specify a CPU thread policy then the CPU thread policy
|
||||
specified by the image (if any) will be used. If both the flavor and image
|
||||
specify a CPU thread policy then they must specify the same policy, otherwise
|
||||
an exception will be raised.
|
||||
|
||||
.. note::
|
||||
|
||||
There is no correlation required between the NUMA topology exposed in the
|
||||
instance and how the instance is actually pinned on the host. This is by
|
||||
design. See this `invalid bug
|
||||
<https://bugs.launchpad.net/nova/+bug/1466780>`_ for more information.
|
||||
|
||||
For more information about image metadata, refer to the `Image metadata`_
|
||||
guide.
|
||||
|
||||
Customizing instance CPU topologies
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. important::
|
||||
|
||||
The functionality described below is currently only supported by the
|
||||
libvirt/KVM driver.
|
||||
|
||||
In addition to configuring how an instance is scheduled on host CPUs, it is
|
||||
possible to configure how CPUs are represented in the instance itself. By
|
||||
default, when instance NUMA placement is not specified, a topology of N
|
||||
sockets, each with one core and one thread, is used for an instance, where N
|
||||
corresponds to the number of instance vCPUs requested. When instance NUMA
|
||||
placement is specified, the number of sockets is fixed to the number of host
|
||||
NUMA nodes to use and the total number of instance CPUs is split over these
|
||||
sockets.
|
||||
|
||||
Some workloads benefit from a custom topology. For example, in some operating
|
||||
systems, a different license may be needed depending on the number of CPU
|
||||
sockets. To configure a flavor to use a maximum of two sockets, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:cpu_sockets=2
|
||||
|
||||
Similarly, to configure a flavor to use one core and one thread, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large \
|
||||
--property hw:cpu_cores=1 \
|
||||
--property hw:cpu_threads=1
|
||||
|
||||
.. caution::
|
||||
|
||||
If specifying all values, the product of sockets multiplied by cores
|
||||
multiplied by threads must equal the number of instance vCPUs. If specifying
|
||||
any one of these values or the multiple of two values, the values must be a
|
||||
factor of the number of instance vCPUs to prevent an exception. For example,
|
||||
specifying ``hw:cpu_sockets=2`` on a host with an odd number of cores fails.
|
||||
Similarly, specifying ``hw:cpu_cores=2`` and ``hw:cpu_threads=4`` on a host
|
||||
with ten cores fails.
|
||||
|
||||
For more information about the syntax for ``hw:cpu_sockets``, ``hw:cpu_cores``
|
||||
and ``hw:cpu_threads``, refer to the `Flavors`_ guide.
|
||||
|
||||
It is also possible to set upper limits on the number of sockets, cores, and
|
||||
threads used. Unlike the hard values above, it is not necessary for this exact
|
||||
number to used because it only provides a limit. This can be used to provide
|
||||
some flexibility in scheduling, while ensuring certains limits are not
|
||||
exceeded. For example, to ensure no more than two sockets are defined in the
|
||||
instance topology, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property=hw:cpu_max_sockets=2
|
||||
|
||||
For more information about the syntax for ``hw:cpu_max_sockets``,
|
||||
``hw:cpu_max_cores``, and ``hw:cpu_max_threads``, refer to the `Flavors`_
|
||||
guide.
|
||||
|
||||
Applications are frequently packaged as images. For applications that prefer
|
||||
certain CPU topologies, configure image metadata to hint that created instances
|
||||
should have a given topology regardless of flavor. To configure an image to
|
||||
request a two-socket, four-core per socket topology, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack image set [IMAGE_ID] \
|
||||
--property hw_cpu_sockets=2 \
|
||||
--property hw_cpu_cores=4
|
||||
|
||||
To constrain instances to a given limit of sockets, cores or threads, use the
|
||||
``max_`` variants. To configure an image to have a maximum of two sockets and a
|
||||
maximum of one thread, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack image set [IMAGE_ID] \
|
||||
--property hw_cpu_max_sockets=2 \
|
||||
--property hw_cpu_max_threads=1
|
||||
|
||||
The value specified in the flavor is treated as the abolute limit. The image
|
||||
limits are not permitted to exceed the flavor limits, they can only be equal
|
||||
to or lower than what the flavor defines. By setting a ``max`` value for
|
||||
sockets, cores, or threads, administrators can prevent users configuring
|
||||
topologies that might, for example, incur an additional licensing fees.
|
||||
|
||||
For more information about image metadata, refer to the `Image metadata`_
|
||||
guide.
|
||||
|
||||
.. Links
|
||||
.. _`Scheduling`: https://docs.openstack.org/ocata/config-reference/compute/schedulers.html
|
||||
.. _`Flavors`: https://docs.openstack.org/admin-guide/compute-flavors.html
|
||||
.. _`Image metadata`: https://docs.openstack.org/image-guide/image-metadata.html
|
||||
.. _`discussion`: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090367.html
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
==========================================
|
||||
Compute service node firewall requirements
|
||||
==========================================
|
||||
|
||||
Console connections for virtual machines, whether direct or through a
|
||||
proxy, are received on ports ``5900`` to ``5999``. The firewall on each
|
||||
Compute service node must allow network traffic on these ports.
|
||||
|
||||
This procedure modifies the iptables firewall to allow incoming
|
||||
connections to the Compute services.
|
||||
|
||||
**Configuring the service-node firewall**
|
||||
|
||||
#. Log in to the server that hosts the Compute service, as root.
|
||||
|
||||
#. Edit the ``/etc/sysconfig/iptables`` file, to add an INPUT rule that
|
||||
allows TCP traffic on ports from ``5900`` to ``5999``. Make sure the new
|
||||
rule appears before any INPUT rules that REJECT traffic:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
-A INPUT -p tcp -m multiport --dports 5900:5999 -j ACCEPT
|
||||
|
||||
#. Save the changes to the ``/etc/sysconfig/iptables`` file, and restart the
|
||||
``iptables`` service to pick up the changes:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ service iptables restart
|
||||
|
||||
#. Repeat this process for each Compute service node.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
=================================
|
||||
Managing the cloud with euca2ools
|
||||
=================================
|
||||
|
||||
The ``euca2ools`` command-line tool provides a command line interface to EC2
|
||||
API calls. For more information, see the `Official Eucalyptus Documentation
|
||||
<http://docs.hpcloud.com/eucalyptus/>`_.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 123 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 177 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 93 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 165 KiB |
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
|
|
@ -0,0 +1,824 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
|
||||
<!-- Generated by Microsoft Visio 11.0, SVG Export, v1.0 SCH_5009_V00_NUAC-VNC_OpenStack.svg Page-1 -->
|
||||
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ev="http://www.w3.org/2001/xml-events"
|
||||
xmlns:v="http://schemas.microsoft.com/visio/2003/SVGExtensions/" width="11.1137in" height="4.39565in"
|
||||
viewBox="0 0 800.187 316.487" xml:space="preserve" color-interpolation-filters="sRGB" class="st22">
|
||||
<title>Schéma Réseau</title>
|
||||
<v:documentProperties v:langID="1033" v:metric="true" v:viewMarkup="false">
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvNoAutoConnect" v:val="VT0(0):26"/>
|
||||
</v:userDefs>
|
||||
</v:documentProperties>
|
||||
|
||||
<style type="text/css">
|
||||
<![CDATA[
|
||||
.st1 {fill:#ffffff;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
|
||||
.st2 {fill:none;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
|
||||
.st3 {marker-end:url(#mrkr13-10);stroke:#595959;stroke-linecap:round;stroke-linejoin:round;stroke-width:1.5}
|
||||
.st4 {fill:#595959;fill-opacity:1;stroke:#595959;stroke-opacity:1;stroke-width:0.37313432835821}
|
||||
.st5 {fill:#595959;stroke:none;stroke-linecap:butt;stroke-width:0.75}
|
||||
.st6 {fill:#ffffff;stroke:#595959;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.25}
|
||||
.st7 {fill:#3f3f3f;font-family:Calibri;font-size:0.666664em}
|
||||
.st8 {fill:#ff00ff;fill-opacity:0}
|
||||
.st9 {stroke:#595959;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:0;stroke-width:0.72}
|
||||
.st10 {fill:url(#grad32-50);stroke:#595959;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.72}
|
||||
.st11 {fill:url(#grad32-50);visibility:hidden}
|
||||
.st12 {stroke:#595959;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.72}
|
||||
.st13 {font-size:1em}
|
||||
.st14 {visibility:visible}
|
||||
.st15 {fill:#d8d8d8;stroke:#d8d8d8;stroke-linecap:round;stroke-linejoin:round;stroke-width:1}
|
||||
.st16 {fill:#ffffff;stroke:#595959;stroke-linecap:round;stroke-linejoin:round;stroke-width:1}
|
||||
.st17 {fill:#ffffff;stroke:#595959;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
|
||||
.st18 {fill:none}
|
||||
.st19 {stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:1;visibility:hidden}
|
||||
.st20 {fill:#000000;font-family:Calibri;font-size:0.666664em}
|
||||
.st21 {fill:#595959;font-family:Calibri;font-size:1.5em}
|
||||
.st22 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
|
||||
]]>
|
||||
</style>
|
||||
|
||||
<defs id="Patterns_And_Gradients">
|
||||
<pattern id="grad32-50" v:fillPattern="32" v:foreground="#ffffff" v:background="#ffffff" x="0" y="0" width="1" height="1"
|
||||
patternContentUnits="objectBoundingBox">
|
||||
<path d="M 0 1 L 0 0 L 1 0 z" style="fill:url(#grad27-51)"/>
|
||||
<path d="M 0 1 L 1 1 L 1 0 z" style="fill:url(#grad28-52)"/>
|
||||
</pattern>
|
||||
<linearGradient id="grad27-51" v:fillPattern="32" v:foreground="#ffffff" v:background="#ffffff" x1="1" y1="0" x2="0" y2="0">
|
||||
<stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/>
|
||||
<stop offset="1" style="stop-color:#ffffff;stop-opacity:1"/>
|
||||
</linearGradient>
|
||||
<linearGradient id="grad28-52" v:fillPattern="32" v:foreground="#ffffff" v:background="#ffffff" x1="0" y1="0" x2="0" y2="1">
|
||||
<stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/>
|
||||
<stop offset="1" style="stop-color:#ffffff;stop-opacity:1"/>
|
||||
</linearGradient>
|
||||
</defs>
|
||||
<defs id="Markers">
|
||||
<g id="lend13">
|
||||
<path d="M 3 1 L 0 0 L 3 -1 L 3 1 " style="stroke:none"/>
|
||||
</g>
|
||||
<marker id="mrkr13-10" class="st4" v:arrowType="13" v:arrowSize="2" v:setback="8.04" refX="-8.04" orient="auto"
|
||||
markerUnits="strokeWidth" overflow="visible">
|
||||
<use xlink:href="#lend13" transform="scale(-2.68,-2.68) "/>
|
||||
</marker>
|
||||
</defs>
|
||||
<g v:mID="4" v:index="1" v:groupContext="backgroundPage">
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvVisioCreated" v:prompt="" v:val="VT0(0):26"/>
|
||||
</v:userDefs>
|
||||
<title>VBackground-1</title>
|
||||
<v:pageProperties width="11.1137" height="4.39565" v:drawingScale="0.0393701" v:pageScale="0.0393701" v:drawingUnits="24"
|
||||
v:shadowOffsetX="8.50394" v:shadowOffsetY="-8.50394"/>
|
||||
<g id="shape1-1" v:mID="1" v:groupContext="shape">
|
||||
<title>Solid</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="Background" v:val="VT0(0):26"/>
|
||||
<v:ud v:nameU="visVersion" v:val="VT0(14):26"/>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(DoNotContain)"/>
|
||||
<v:ud v:nameU="msvVisioCreated" v:prompt="" v:val="VT0(0):26"/>
|
||||
</v:userDefs>
|
||||
<rect x="0" y="0" width="800.187" height="316.487" class="st1"/>
|
||||
</g>
|
||||
<g id="shape13-3" v:mID="13" v:groupContext="shape" transform="translate(18,-18)">
|
||||
<title>None </title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="Background" v:val="VT0(3):26"/>
|
||||
<v:ud v:nameU="visVersion" v:val="VT0(14):26"/>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(DoNotContain)"/>
|
||||
<v:ud v:nameU="msvVisioCreated" v:prompt="" v:val="VT0(0):26"/>
|
||||
</v:userDefs>
|
||||
<rect x="0" y="36" width="764.187" height="280.487" class="st2"/>
|
||||
</g>
|
||||
</g>
|
||||
<g v:mID="0" v:index="2" v:groupContext="foregroundPage">
|
||||
<v:custProps>
|
||||
<v:cp v:nameU="AskOnDrop" v:lbl="Ask On Drop" v:type="3" v:langID="1033" v:val="VT4(TRUE)"/>
|
||||
</v:custProps>
|
||||
<title>Page-1</title>
|
||||
<v:pageProperties v:drawingScale="0.0393701" v:pageScale="0.0393701" v:drawingUnits="24" v:shadowOffsetX="8.50394"
|
||||
v:shadowOffsetY="-8.50394"/>
|
||||
<v:layer v:name="Connector" v:index="0"/>
|
||||
<v:layer v:name="Annotations" v:index="1"/>
|
||||
<v:layer v:name="Flowchart" v:index="2"/>
|
||||
<v:layer v:name="Alarm and Access Control" v:index="3"/>
|
||||
<v:layer v:name="Security" v:index="4"/>
|
||||
<v:layer v:name="Electrical Fixture" v:index="5"/>
|
||||
<g id="shape58-5" v:mID="58" v:groupContext="shape" transform="translate(129.862,-80.5441)">
|
||||
<title>Sheet.58</title>
|
||||
<path d="M0 316.49 L191.83 316.49" class="st3"/>
|
||||
</g>
|
||||
<g id="shape10-11" v:mID="10" v:groupContext="shape" transform="translate(65.8928,-222.597)">
|
||||
<title>User.50</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M37.69 272.6 A19.1385 18.8371 0 0 1 34.74 274.19 L27.03 289.13 L19.32 274.19 A18.9128 18.615 0 0 1 16.37 272.6
|
||||
A28.4427 27.9947 -180 0 0 0.06 299.75 A21.5444 21.2051 -180 0 0 27.03 315.67 A21.5444 21.2051 -180 0 0 54
|
||||
299.75 A28.4427 27.9947 -180 0 0 37.69 272.6 ZM27.03 310.36 A18.859 18.562 0 0 1 5.45 299.75 A23.723 23.3494
|
||||
0 0 1 15.82 279.14 L27.03 300.85 L38.24 279.14 A23.7188 23.3453 0 0 1 48.6 299.75 A18.859 18.562 0 0 1 27.03
|
||||
310.36 ZM27.03 241.35 A16.1844 15.9295 -180 0 0 10.85 257.27 A16.1844 15.9295 -180 0 0 27.03 273.2 A16.1844
|
||||
15.9295 -180 0 0 43.21 257.27 A16.1844 15.9295 -180 0 0 27.03 241.35 ZM27.03 267.89 A10.7988 10.6288 0 0
|
||||
1 16.24 257.27 A10.7988 10.6288 0 0 1 27.03 246.66 A10.7988 10.6288 0 0 1 37.82 257.27 A10.7988 10.6288
|
||||
0 0 1 27.03 267.89 Z" class="st5"/>
|
||||
</g>
|
||||
<g id="group8-13" transform="translate(55.864,-214.576)" v:mID="8" v:groupContext="group" v:layerMember="2">
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvThemeColors" v:val="VT0(2):26"/>
|
||||
<v:ud v:nameU="visVersion" v:val="VT0(14):26"/>
|
||||
<v:ud v:nameU="visKeywords" v:val="VT4(SharePoint;Workflow;MOSS;SharePoint;Foundation)"/>
|
||||
<v:ud v:nameU="SolSH" v:val="VT4({21c62d3a-0c14-434d-b64e-fc6e5bbfa482})"/>
|
||||
<v:ud v:nameU="ShapeClass" v:val="VT0(3):26"/>
|
||||
<v:ud v:nameU="ShapeType" v:val="VT0(28):26"/>
|
||||
<v:ud v:nameU="msvAtomicShape" v:val="VT0(1):26"/>
|
||||
<v:ud v:nameU="msvShapeCategories" v:val="VT4()"/>
|
||||
</v:userDefs>
|
||||
<title>Add list item permissions</title>
|
||||
</g>
|
||||
<g id="group3-14" transform="translate(346.758,-207.395)" v:mID="3" v:groupContext="group">
|
||||
<title>Sheet.3</title>
|
||||
<g id="shape80-15" v:mID="80" v:groupContext="shape" transform="translate(0,-17.1067)">
|
||||
<title>Network.80</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M13.79 255.67 L13.79 280.45 L50.55 280.45 L50.55 255.67 L13.79 255.67 ZM11.49 282.7 L11.49 253.42 L52.84
|
||||
253.42 L52.84 282.7 L11.49 282.7 ZM59.74 309.73 L59.74 305.22 L43.65 305.22 L43.65 309.73 L59.74 309.73
|
||||
ZM39.06 311.98 L39.06 302.97 L25.27 302.97 L25.27 311.98 L39.06 311.98 ZM34.46 291.71 L29.87 291.71
|
||||
L29.87 298.47 L34.46 298.47 L34.46 291.71 ZM6.89 287.2 L57.44 287.2 L57.44 248.91 L6.89 248.91 L6.89
|
||||
287.2 ZM20.68 309.73 L20.68 305.22 L4.6 305.22 L4.6 309.73 L20.68 309.73 ZM61.65 300.72 C63.13 300.72
|
||||
64.33 301.9 64.33 303.35 L64.33 311.6 C64.33 313.06 63.13 314.23 61.65 314.23 L43.57 314.23 C43.38 315.5
|
||||
42.31 316.49 40.97 316.49 L23.36 316.49 C22.02 316.49 20.95 315.5 20.76 314.23 L2.68 314.23 C1.2 314.23
|
||||
0 313.06 0 311.6 L0 303.35 C-0 301.9 1.2 300.72 2.68 300.72 L20.76 300.72 C20.95 299.45 22.02 298.47
|
||||
23.36 298.47 L25.27 298.47 L25.27 291.71 L4.98 291.71 C3.5 291.71 2.3 290.53 2.3 289.08 L2.3 247.04
|
||||
C2.3 245.58 3.5 244.41 4.98 244.41 L59.35 244.41 C60.83 244.41 62.03 245.58 62.03 247.04 L62.03 289.08
|
||||
C62.03 290.53 60.83 291.71 59.35 291.71 L39.06 291.71 L39.06 298.47 L40.97 298.47 C42.31 298.47 43.38
|
||||
299.45 43.57 300.72 L61.65 300.72 Z" class="st5"/>
|
||||
</g>
|
||||
<g id="shape2-17" v:mID="2" v:groupContext="shape" transform="translate(6.23971,1.13687E-013)">
|
||||
<title>Sheet.2</title>
|
||||
<desc>Nova-api</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="25.9256" cy="309.172" width="51.86" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="51.8511" height="14.6291" class="st6"/>
|
||||
<text x="11.35" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>Nova-api</text> </g>
|
||||
</g>
|
||||
<g id="group4-20" transform="translate(648.373,-207.395)" v:mID="4" v:groupContext="group">
|
||||
<title>Sheet.4</title>
|
||||
<g id="shape7-21" v:mID="7" v:groupContext="shape" transform="translate(0,-17.1067)">
|
||||
<title>Network.80</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M13.79 255.67 L13.79 280.45 L50.55 280.45 L50.55 255.67 L13.79 255.67 ZM11.49 282.7 L11.49 253.42 L52.84
|
||||
253.42 L52.84 282.7 L11.49 282.7 ZM59.74 309.73 L59.74 305.22 L43.65 305.22 L43.65 309.73 L59.74 309.73
|
||||
ZM39.06 311.98 L39.06 302.97 L25.27 302.97 L25.27 311.98 L39.06 311.98 ZM34.46 291.71 L29.87 291.71
|
||||
L29.87 298.47 L34.46 298.47 L34.46 291.71 ZM6.89 287.2 L57.44 287.2 L57.44 248.91 L6.89 248.91 L6.89
|
||||
287.2 ZM20.68 309.73 L20.68 305.22 L4.6 305.22 L4.6 309.73 L20.68 309.73 ZM61.65 300.72 C63.13 300.72
|
||||
64.33 301.9 64.33 303.35 L64.33 311.6 C64.33 313.06 63.13 314.23 61.65 314.23 L43.57 314.23 C43.38 315.5
|
||||
42.31 316.49 40.97 316.49 L23.36 316.49 C22.02 316.49 20.95 315.5 20.76 314.23 L2.68 314.23 C1.2 314.23
|
||||
0 313.06 0 311.6 L0 303.35 C-0 301.9 1.2 300.72 2.68 300.72 L20.76 300.72 C20.95 299.45 22.02 298.47
|
||||
23.36 298.47 L25.27 298.47 L25.27 291.71 L4.98 291.71 C3.5 291.71 2.3 290.53 2.3 289.08 L2.3 247.04
|
||||
C2.3 245.58 3.5 244.41 4.98 244.41 L59.35 244.41 C60.83 244.41 62.03 245.58 62.03 247.04 L62.03 289.08
|
||||
C62.03 290.53 60.83 291.71 59.35 291.71 L39.06 291.71 L39.06 298.47 L40.97 298.47 C42.31 298.47 43.38
|
||||
299.45 43.57 300.72 L61.65 300.72 Z" class="st5"/>
|
||||
</g>
|
||||
<g id="shape12-23" v:mID="12" v:groupContext="shape" transform="translate(-7.82161,1.13687E-013)">
|
||||
<title>Sheet.12</title>
|
||||
<desc>Compute node</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="40.2066" cy="309.172" width="80.42" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="80.4132" height="14.6291" class="st6"/>
|
||||
<text x="16.03" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>Compute node</text> </g>
|
||||
</g>
|
||||
<g id="shape13-26" v:mID="13" v:groupContext="shape" transform="translate(406.694,-260.743)">
|
||||
<title>Sheet.13</title>
|
||||
<path d="M0 316.49 L228.74 316.49" class="st3"/>
|
||||
</g>
|
||||
<g id="shape14-31" v:mID="14" v:groupContext="shape" transform="translate(430.299,-254.095)">
|
||||
<title>Sheet.14</title>
|
||||
<desc>The api sends a «get_vnc_console» message</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="97.9899" cy="309.172" width="195.98" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="195.98" height="14.6291" class="st6"/>
|
||||
<text x="25.77" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>The api sends a «get_vnc_console» message</text> </g>
|
||||
<g id="group19-34" transform="translate(599.283,-167.07)" v:mID="19" v:groupContext="group">
|
||||
<title>Sheet.19</title>
|
||||
</g>
|
||||
<g id="shape21-35" v:mID="21" v:groupContext="shape" transform="translate(998.256,109.463) rotate(90)">
|
||||
<title>Sheet.21</title>
|
||||
<path d="M0 316.49 L78.67 316.49" class="st3"/>
|
||||
</g>
|
||||
<g id="group18-40" transform="translate(635.963,-170.045)" v:mID="18" v:groupContext="group">
|
||||
<title>Sheet.18</title>
|
||||
<g id="shape20-41" v:mID="20" v:groupContext="shape">
|
||||
<title>Sheet.20</title>
|
||||
<desc>Generates a token</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="42.2906" cy="309.172" width="84.59" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="84.5811" height="14.6291" class="st6"/>
|
||||
<text x="4" y="311.57" class="st7" v:langID="1036"><v:paragraph/><v:tabList/>Generates a token</text> </g>
|
||||
<g id="shape22-44" v:mID="22" v:groupContext="shape" transform="translate(81.0658,-3.50165)">
|
||||
<title>Sheet.22</title>
|
||||
<path d="M2.87 316.25 A1.58888 1.60577 -180 0 0 2.91 316.27 a0.0367968 0.0364098 90 0 1 -0.0368398 -0.0219852 ZM2.91
|
||||
316.27 A1.58888 1.60577 -180 0 0 4.63 316.18 A5.54577 5.60472 -180 0 0 6.01 314.87 A14.0646 14.2141
|
||||
-180 0 0 7.52 310.98 L11.13 308.91 L12.46 306.1 L16.52 303.74 L17.58 301.61 L17.58 299.72 L16.29 298.98
|
||||
L7.23 304.3 A2.02885 2.05041 -180 0 0 6.95 303.77 A1.74485 1.76339 -180 0 0 6.16 303.06 A1.74485 1.76339
|
||||
-180 0 0 4.87 303.01 A1.70133 1.68344 90 0 1 6.16 303.06 L5.48 302.63 A2.21204 2.18877 -90 0 0 3.34
|
||||
302.37 A6.27998 6.21394 -90 0 0 1.27 305.16 A15.3607 15.1992 -90 0 0 0 310.91 A8.22802 8.14148 -90 0
|
||||
0 1.29 315.35 L2.9 316.29 L2.91 316.27 ZM1.29 311.64 A15.563 15.3993 90 0 1 2.24 306.64 A17.2407 17.424
|
||||
-180 0 0 1.29 311.64 A8.18363 8.27061 -180 0 0 1.81 314.57 A6.45582 6.38792 90 0 1 1.29 311.64 Z"
|
||||
class="st8"/>
|
||||
<path d="M2.87 316.25 A1.58888 1.60577 -180 0 0 2.91 316.27 a0.0367968 0.0364098 90 0 1 -0.0368398 -0.0219852M2.91
|
||||
316.27 A1.58888 1.60577 -180 0 0 4.63 316.18 A5.54577 5.60472 -180 0 0 6.01 314.87 A14.0646 14.2141
|
||||
-180 0 0 7.52 310.98 L11.13 308.91 L12.46 306.1 L16.52 303.74 L17.58 301.61 L17.58 299.72 L16.29 298.98
|
||||
L7.23 304.3 A2.02885 2.05041 -180 0 0 6.95 303.77 A1.74485 1.76339 -180 0 0 6.16 303.06 A1.74485 1.76339
|
||||
-180 0 0 4.87 303.01 A1.70133 1.68344 90 0 1 6.16 303.06 L5.48 302.63 A2.21204 2.18877 -90 0 0 3.34
|
||||
302.37 A6.27998 6.21394 -90 0 0 1.27 305.16 A15.3607 15.1992 -90 0 0 0 310.91 A8.22802 8.14148 -90 0
|
||||
0 1.29 315.35 L2.9 316.29M1.29 311.64 A15.563 15.3993 90 0 1 2.24 306.64 A17.2407 17.424 -180 0 0 1.29
|
||||
311.64 A8.18363 8.27061 -180 0 0 1.81 314.57 A6.45582 6.38792 90 0 1 1.29 311.64" class="st9"/>
|
||||
</g>
|
||||
<g id="shape23-47" v:mID="23" v:groupContext="shape" transform="translate(82.3594,-3.50165)">
|
||||
<title>Sheet.23</title>
|
||||
<path d="M16.28 299.72 L16.28 301.61 L15.23 303.74 L11.17 306.1 L9.83 308.91 L6.23 310.98 A14.0646 14.2141 0 0 1
|
||||
4.72 314.87 A5.54577 5.60472 0 0 1 3.34 316.18 A1.58888 1.60577 0 0 1 1 315.63 A8.18363 8.27061 0 0
|
||||
1 0 311.64 A17.2407 17.424 0 0 1 0.99 306.5 A7.30166 7.37926 0 0 1 3.34 303.11 A1.74485 1.76339 0 0
|
||||
1 5.65 303.77 A4.64183 4.69116 0 0 1 6.38 305.5 L16.28 299.72 Z" class="st10"/>
|
||||
</g>
|
||||
<g id="shape24-53" v:mID="24" v:groupContext="shape" transform="translate(138.107,-3.1212) rotate(10)">
|
||||
<title>Sheet.24</title>
|
||||
<ellipse cx="0.980152" cy="314.562" rx="0.980152" ry="1.92488" class="st11"/>
|
||||
<ellipse cx="0.980152" cy="314.562" rx="0.980152" ry="1.92488" class="st12"/>
|
||||
</g>
|
||||
<g id="shape25-57" v:mID="25" v:groupContext="shape" transform="translate(88.2988,-14.4874)">
|
||||
<title>Sheet.25</title>
|
||||
<path d="M0 315.29 L0.44 316.49 L10.34 310.7 L9.05 309.96 L0 315.29 Z" class="st10"/>
|
||||
</g>
|
||||
<g id="shape26-60" v:mID="26" v:groupContext="shape" transform="translate(81.0658,-3.70182)">
|
||||
<title>Sheet.26</title>
|
||||
<path d="M2.9 316.49 A6.38792 6.45582 0 0 1 1.29 311.84 A15.3993 15.563 0 0 1 2.29 306.7 A8.18314 8.27011 0 0 1 4.63
|
||||
303.32 A1.68344 1.70133 0 0 1 6.16 303.26 L5.48 302.83 A2.18877 2.21204 -180 0 0 3.34 302.57 A6.21394
|
||||
6.27998 -180 0 0 1.27 305.36 A15.1992 15.3607 -180 0 0 0 311.11 A8.14148 8.22802 -180 0 0 1.29 315.55
|
||||
L2.9 316.49 Z" class="st10"/>
|
||||
</g>
|
||||
<g id="shape27-63" v:mID="27" v:groupContext="shape" transform="translate(83.6184,-7.75985)">
|
||||
<title>Sheet.27</title>
|
||||
<path d="M0.76 313.73 A3.52228 3.55971 0 0 1 0 316.02 a0.626726 0.633387 -180 0 0 0.946178 0.363513 A1.85316 1.87285
|
||||
-180 0 0 1.62 315.39 A3.64133 3.68003 -180 0 0 1.79 313.47 a0.88788 0.897317 -180 0 0 -0.643292 -0.777107
|
||||
a0.935131 0.94507 -180 0 0 -0.595176 0.242998 A3.2863 3.32123 0 0 1 0.76 313.73 Z" class="st10"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="group34-66" transform="translate(640.024,-18.25)" v:mID="34" v:groupContext="group">
|
||||
<title>Sheet.34</title>
|
||||
<g id="shape16-67" v:mID="16" v:groupContext="shape" transform="translate(6.59125,-22.7607)">
|
||||
<title>Configure</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M64.49 290.4 C63.12 289.83 58.77 288 58.77 287.99 L59.05 284.38 L59.28 281.35 L58.89 275.55 L61.76 273.9
|
||||
C61.76 273.9 63.22 273.31 64.57 272.75 C63.6 270.38 63.19 269.4 62.21 267.03 C60.85 267.59 56.34 269.44
|
||||
56.34 269.44 L54.11 266.66 C53.03 265.31 51.7 264.04 50.02 262.75 L47.38 260.71 L48.45 257.48 C48.45
|
||||
257.48 49.08 255.97 49.67 254.51 C47.3 253.54 46.31 253.14 43.94 252.17 C43.32 253.67 41.43 258.25 41.43
|
||||
258.25 L37.93 257.91 C36.15 257.73 34.3 257.77 32.45 258.02 L29.12 258.46 L27.57 255.42 C27.57 255.42
|
||||
26.89 253.81 26.22 252.24 C23.86 253.24 22.88 253.65 20.51 254.64 C21.22 256.31 23.2 261 23.2 261 L20.5
|
||||
263.23 C19.22 264.29 18.03 265.54 16.85 267.07 L14.83 269.7 L11.58 268.66 C11.58 268.66 9.82 267.95
|
||||
8.08 267.26 C7.12 269.64 6.73 270.63 5.77 273.01 C7.54 273.71 12.24 275.59 12.24 275.59 C12.24 275.59
|
||||
11.95 280.91 11.93 281.34 C11.95 281.72 12.03 282.91 12.03 282.93 C12.03 282.93 12.3 285.75 12.3 285.75
|
||||
L10.61 287.28 C10.09 287.8 9.91 287.93 5.69 289.59 C6.62 291.98 7.01 292.96 7.94 295.35 C9.7 294.67
|
||||
14.62 292.76 14.62 292.76 L17.17 296.23 C17.95 297.19 19.04 298.28 20.37 299.4 L22.87 301.5 L21.76 304.62
|
||||
C21.76 304.62 21.01 306.36 20.26 308.1 C22.61 309.11 23.59 309.53 25.95 310.55 C26.64 308.94 28.69 304.23
|
||||
28.69 304.23 L32.26 304.73 C33.95 304.97 35.76 305 37.65 304.84 L40.9 304.56 L42.35 307.55 C42.35 307.55
|
||||
43.01 309.19 43.66 310.79 C46.04 309.84 47.03 309.45 49.41 308.49 C48.82 307.02 46.93 302.31 46.93 302.31
|
||||
L50.5 299.75 C51.51 298.93 52.67 297.76 53.87 296.31 L55.95 293.79 L59.14 294.87 C59.14 294.87 60.64
|
||||
295.5 62.08 296.11 C63.07 293.74 63.49 292.76 64.49 290.4 ZM63.41 284.94 C63.41 284.94 63.39 285.07
|
||||
63.37 285.18 C63.98 285.44 70.24 288.07 70.24 288.07 L64.42 301.84 C64.42 301.84 58.02 299.15 57.42
|
||||
298.9 C57.34 298.99 57.26 299.08 57.26 299.08 C55.88 300.77 54.51 302.15 53.07 303.29 C53.07 303.29
|
||||
52.6 303.63 52.28 303.86 C52.53 304.49 55.12 310.93 55.12 310.93 L41.21 316.49 C41.21 316.49 38.51 309.78
|
||||
38.27 309.18 C38.16 309.19 38.03 309.2 38.03 309.2 C35.8 309.39 33.65 309.35 31.64 309.06 C31.64 309.06
|
||||
31.51 309.04 31.39 309.02 C31.13 309.64 28.24 316.31 28.24 316.31 L14.48 310.38 C14.48 310.38 17.46
|
||||
303.5 17.72 302.9 C17.63 302.83 17.54 302.75 17.54 302.75 C15.98 301.44 14.7 300.15 13.62 298.81 C13.62
|
||||
298.81 13.3 298.36 13.07 298.06 C12.44 298.3 5.45 301.02 5.45 301.02 L0 287.1 C0 287.1 7.5 284.19 7.51
|
||||
284.18 C7.51 284.18 7.62 284.14 7.73 284.1 C7.69 283.73 7.65 283.22 7.65 283.22 L7.53 281.36 C7.53 281.36
|
||||
7.65 279.03 7.68 278.48 C7.09 278.25 0.06 275.44 0.06 275.44 L5.63 261.57 C5.63 261.57 12.6 264.35 13.22
|
||||
264.6 C13.29 264.5 13.37 264.4 13.37 264.4 C14.74 262.62 16.16 261.13 17.7 259.86 C17.7 259.86 17.8
|
||||
259.78 17.89 259.71 C17.63 259.11 14.76 252.31 14.76 252.31 L28.57 246.5 C28.57 246.5 31.36 253.09 31.62
|
||||
253.71 C31.73 253.69 31.86 253.68 31.86 253.68 C34.06 253.38 36.25 253.34 38.37 253.55 C38.37 253.55
|
||||
38.49 253.56 38.6 253.57 C38.85 252.97 41.54 246.45 41.54 246.45 L55.4 252.13 C55.4 252.13 52.77 258.53
|
||||
52.52 259.14 C52.61 259.21 52.71 259.29 52.71 259.29 C54.66 260.8 56.24 262.31 57.52 263.91 C57.52 263.91
|
||||
57.62 264.02 57.71 264.14 C58.32 263.89 64.61 261.31 64.61 261.31 L70.31 275.14 C70.31 275.14 64.04
|
||||
277.7 63.43 277.95 C63.45 278.07 63.46 278.19 63.46 278.19 C63.6 279.4 63.67 280.41 63.67 281.35 C63.67
|
||||
282.42 63.59 283.56 63.41 284.94 ZM41.49 288.74 C45.56 285.49 46.22 279.57 42.97 275.51 C39.71 271.45
|
||||
33.77 270.79 29.7 274.04 C25.63 277.28 24.97 283.2 28.23 287.26 C31.48 291.32 37.42 291.98 41.49 288.74
|
||||
ZM37.12 267.68 C40.8 268.09 44.09 269.9 46.4 272.78 C51.16 278.72 50.19 287.41 44.23 292.15 C41.35 294.46
|
||||
37.74 295.5 34.07 295.09 C30.39 294.68 27.1 292.87 24.79 289.99 C22.76 287.46 21.77 284.42 21.77 281.4
|
||||
C21.77 277.35 23.55 273.34 26.96 270.62 C29.84 268.32 33.45 267.28 37.12 267.68 Z" class="st5"/>
|
||||
</g>
|
||||
<g id="shape33-69" v:mID="33" v:groupContext="shape">
|
||||
<title>Sheet.33</title>
|
||||
<desc>Libvirt driver</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="40.2066" cy="309.172" width="80.42" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="80.4132" height="14.6291" class="st6"/>
|
||||
<text x="19.54" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>Libvirt driver</text> </g>
|
||||
</g>
|
||||
<g id="group35-72" transform="translate(334.19,-18.25)" v:mID="35" v:groupContext="group">
|
||||
<title>Sheet.35</title>
|
||||
<g id="shape38-73" v:mID="38" v:groupContext="shape" transform="translate(6.59125,-22.7607)">
|
||||
<title>Configure</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M64.49 290.4 C63.12 289.83 58.77 288 58.77 287.99 L59.05 284.38 L59.28 281.35 L58.89 275.55 L61.76 273.9
|
||||
C61.76 273.9 63.22 273.31 64.57 272.75 C63.6 270.38 63.19 269.4 62.21 267.03 C60.85 267.59 56.34 269.44
|
||||
56.34 269.44 L54.11 266.66 C53.03 265.31 51.7 264.04 50.02 262.75 L47.38 260.71 L48.45 257.48 C48.45
|
||||
257.48 49.08 255.97 49.67 254.51 C47.3 253.54 46.31 253.14 43.94 252.17 C43.32 253.67 41.43 258.25 41.43
|
||||
258.25 L37.93 257.91 C36.15 257.73 34.3 257.77 32.45 258.02 L29.12 258.46 L27.57 255.42 C27.57 255.42
|
||||
26.89 253.81 26.22 252.24 C23.86 253.24 22.88 253.65 20.51 254.64 C21.22 256.31 23.2 261 23.2 261 L20.5
|
||||
263.23 C19.22 264.29 18.03 265.54 16.85 267.07 L14.83 269.7 L11.58 268.66 C11.58 268.66 9.82 267.95
|
||||
8.08 267.26 C7.12 269.64 6.73 270.63 5.77 273.01 C7.54 273.71 12.24 275.59 12.24 275.59 C12.24 275.59
|
||||
11.95 280.91 11.93 281.34 C11.95 281.72 12.03 282.91 12.03 282.93 C12.03 282.93 12.3 285.75 12.3 285.75
|
||||
L10.61 287.28 C10.09 287.8 9.91 287.93 5.69 289.59 C6.62 291.98 7.01 292.96 7.94 295.35 C9.7 294.67
|
||||
14.62 292.76 14.62 292.76 L17.17 296.23 C17.95 297.19 19.04 298.28 20.37 299.4 L22.87 301.5 L21.76 304.62
|
||||
C21.76 304.62 21.01 306.36 20.26 308.1 C22.61 309.11 23.59 309.53 25.95 310.55 C26.64 308.94 28.69 304.23
|
||||
28.69 304.23 L32.26 304.73 C33.95 304.97 35.76 305 37.65 304.84 L40.9 304.56 L42.35 307.55 C42.35 307.55
|
||||
43.01 309.19 43.66 310.79 C46.04 309.84 47.03 309.45 49.41 308.49 C48.82 307.02 46.93 302.31 46.93 302.31
|
||||
L50.5 299.75 C51.51 298.93 52.67 297.76 53.87 296.31 L55.95 293.79 L59.14 294.87 C59.14 294.87 60.64
|
||||
295.5 62.08 296.11 C63.07 293.74 63.49 292.76 64.49 290.4 ZM63.41 284.94 C63.41 284.94 63.39 285.07
|
||||
63.37 285.18 C63.98 285.44 70.24 288.07 70.24 288.07 L64.42 301.84 C64.42 301.84 58.02 299.15 57.42
|
||||
298.9 C57.34 298.99 57.26 299.08 57.26 299.08 C55.88 300.77 54.51 302.15 53.07 303.29 C53.07 303.29
|
||||
52.6 303.63 52.28 303.86 C52.53 304.49 55.12 310.93 55.12 310.93 L41.21 316.49 C41.21 316.49 38.51 309.78
|
||||
38.27 309.18 C38.16 309.19 38.03 309.2 38.03 309.2 C35.8 309.39 33.65 309.35 31.64 309.06 C31.64 309.06
|
||||
31.51 309.04 31.39 309.02 C31.13 309.64 28.24 316.31 28.24 316.31 L14.48 310.38 C14.48 310.38 17.46
|
||||
303.5 17.72 302.9 C17.63 302.83 17.54 302.75 17.54 302.75 C15.98 301.44 14.7 300.15 13.62 298.81 C13.62
|
||||
298.81 13.3 298.36 13.07 298.06 C12.44 298.3 5.45 301.02 5.45 301.02 L0 287.1 C0 287.1 7.5 284.19 7.51
|
||||
284.18 C7.51 284.18 7.62 284.14 7.73 284.1 C7.69 283.73 7.65 283.22 7.65 283.22 L7.53 281.36 C7.53 281.36
|
||||
7.65 279.03 7.68 278.48 C7.09 278.25 0.06 275.44 0.06 275.44 L5.63 261.57 C5.63 261.57 12.6 264.35 13.22
|
||||
264.6 C13.29 264.5 13.37 264.4 13.37 264.4 C14.74 262.62 16.16 261.13 17.7 259.86 C17.7 259.86 17.8
|
||||
259.78 17.89 259.71 C17.63 259.11 14.76 252.31 14.76 252.31 L28.57 246.5 C28.57 246.5 31.36 253.09 31.62
|
||||
253.71 C31.73 253.69 31.86 253.68 31.86 253.68 C34.06 253.38 36.25 253.34 38.37 253.55 C38.37 253.55
|
||||
38.49 253.56 38.6 253.57 C38.85 252.97 41.54 246.45 41.54 246.45 L55.4 252.13 C55.4 252.13 52.77 258.53
|
||||
52.52 259.14 C52.61 259.21 52.71 259.29 52.71 259.29 C54.66 260.8 56.24 262.31 57.52 263.91 C57.52 263.91
|
||||
57.62 264.02 57.71 264.14 C58.32 263.89 64.61 261.31 64.61 261.31 L70.31 275.14 C70.31 275.14 64.04
|
||||
277.7 63.43 277.95 C63.45 278.07 63.46 278.19 63.46 278.19 C63.6 279.4 63.67 280.41 63.67 281.35 C63.67
|
||||
282.42 63.59 283.56 63.41 284.94 ZM41.49 288.74 C45.56 285.49 46.22 279.57 42.97 275.51 C39.71 271.45
|
||||
33.77 270.79 29.7 274.04 C25.63 277.28 24.97 283.2 28.23 287.26 C31.48 291.32 37.42 291.98 41.49 288.74
|
||||
ZM37.12 267.68 C40.8 268.09 44.09 269.9 46.4 272.78 C51.16 278.72 50.19 287.41 44.23 292.15 C41.35 294.46
|
||||
37.74 295.5 34.07 295.09 C30.39 294.68 27.1 292.87 24.79 289.99 C22.76 287.46 21.77 284.42 21.77 281.4
|
||||
C21.77 277.35 23.55 273.34 26.96 270.62 C29.84 268.32 33.45 267.28 37.12 267.68 Z" class="st5"/>
|
||||
</g>
|
||||
<g id="shape39-75" v:mID="39" v:groupContext="shape" transform="translate(-14.0613,0)">
|
||||
<title>Sheet.39</title>
|
||||
<desc>Nova-consoleauth</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="49.9836" cy="309.172" width="99.97" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="99.9672" height="14.6291" class="st6"/>
|
||||
<text x="20.4" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>Nova-consoleauth</text> </g>
|
||||
</g>
|
||||
<g id="shape41-78" v:mID="41" v:groupContext="shape" transform="translate(694.18,109.463) rotate(90)">
|
||||
<title>Sheet.41</title>
|
||||
<path d="M0 316.49 L78.67 316.49" class="st3"/>
|
||||
</g>
|
||||
<g id="shape46-83" v:mID="46" v:groupContext="shape" transform="translate(414.604,-167.07)">
|
||||
<title>Sheet.46</title>
|
||||
<path d="M2.87 316.25 A1.58888 1.60577 -180 0 0 2.91 316.27 a0.0367968 0.0364098 90 0 1 -0.0368398 -0.0219852 ZM2.91
|
||||
316.27 A1.58888 1.60577 -180 0 0 4.63 316.18 A5.54577 5.60472 -180 0 0 6.01 314.87 A14.0646 14.2141 -180
|
||||
0 0 7.52 310.98 L11.13 308.91 L12.46 306.1 L16.52 303.74 L17.58 301.61 L17.58 299.72 L16.29 298.98 L7.23
|
||||
304.3 A2.02885 2.05041 -180 0 0 6.95 303.77 A1.74485 1.76339 -180 0 0 6.16 303.06 A1.74485 1.76339 -180
|
||||
0 0 4.87 303.01 A1.70133 1.68344 90 0 1 6.16 303.06 L5.48 302.63 A2.21204 2.18877 -90 0 0 3.34 302.37 A6.27998
|
||||
6.21394 -90 0 0 1.27 305.16 A15.3607 15.1992 -90 0 0 0 310.91 A8.22802 8.14148 -90 0 0 1.29 315.35 L2.9
|
||||
316.29 L2.91 316.27 ZM1.29 311.64 A15.563 15.3993 90 0 1 2.24 306.64 A17.2407 17.424 -180 0 0 1.29 311.64
|
||||
A8.18363 8.27061 -180 0 0 1.81 314.57 A6.45582 6.38792 90 0 1 1.29 311.64 Z" class="st8"/>
|
||||
<path d="M2.87 316.25 A1.58888 1.60577 -180 0 0 2.91 316.27 a0.0367968 0.0364098 90 0 1 -0.0368398 -0.0219852M2.91 316.27
|
||||
A1.58888 1.60577 -180 0 0 4.63 316.18 A5.54577 5.60472 -180 0 0 6.01 314.87 A14.0646 14.2141 -180 0 0 7.52
|
||||
310.98 L11.13 308.91 L12.46 306.1 L16.52 303.74 L17.58 301.61 L17.58 299.72 L16.29 298.98 L7.23 304.3 A2.02885
|
||||
2.05041 -180 0 0 6.95 303.77 A1.74485 1.76339 -180 0 0 6.16 303.06 A1.74485 1.76339 -180 0 0 4.87 303.01
|
||||
A1.70133 1.68344 90 0 1 6.16 303.06 L5.48 302.63 A2.21204 2.18877 -90 0 0 3.34 302.37 A6.27998 6.21394 -90
|
||||
0 0 1.27 305.16 A15.3607 15.1992 -90 0 0 0 310.91 A8.22802 8.14148 -90 0 0 1.29 315.35 L2.9 316.29M1.29
|
||||
311.64 A15.563 15.3993 90 0 1 2.24 306.64 A17.2407 17.424 -180 0 0 1.29 311.64 A8.18363 8.27061 -180 0 0
|
||||
1.81 314.57 A6.45582 6.38792 90 0 1 1.29 311.64" class="st9"/>
|
||||
</g>
|
||||
<g id="group42-86" transform="translate(303.43,-158.692)" v:mID="42" v:groupContext="group">
|
||||
<title>Sheet.42</title>
|
||||
<g id="shape44-87" v:mID="44" v:groupContext="shape">
|
||||
<title>Sheet.44</title>
|
||||
<desc>Sends «authorize_console » message</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="80.9592" cy="309.172" width="161.92" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="161.918" height="14.6291" class="st6"/>
|
||||
<text x="4" y="311.57" class="st7" v:langID="1036"><v:paragraph/><v:tabList/>Sends «authorize_console » message</text> </g>
|
||||
<g id="group55-90" transform="translate(154.888,-9.13059)" v:mID="55" v:groupContext="group">
|
||||
<title>Sheet.55</title>
|
||||
<g id="shape56-91" v:mID="56" v:groupContext="shape" transform="translate(0.515073,-0.812731)">
|
||||
<title>Sheet.56</title>
|
||||
<rect x="0" y="304.581" width="11.4206" height="11.9056" class="st1"/>
|
||||
</g>
|
||||
<g id="shape59-93" v:mID="59" v:groupContext="shape">
|
||||
<title>Document</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M2.41 312.82 L2.41 312.3 L10.12 312.3 L10.12 312.82 L2.41 312.82 ZM2.41 310.73 L2.41 310.2 L10.12 310.2
|
||||
L10.12 310.73 L2.41 310.73 ZM2.41 308.63 L2.41 308.11 L10.12 308.11 L10.12 308.63 L2.41 308.63 ZM2.41
|
||||
306.54 L2.41 306.01 L10.12 306.01 L10.12 306.54 L2.41 306.54 ZM2.41 304.44 L2.41 303.92 L7.25 303.92
|
||||
L7.25 304.44 L2.41 304.44 ZM11.57 315.44 L11.57 303.92 L8.68 303.92 L8.68 300.78 L0.96 300.78 L0.96
|
||||
315.44 L11.57 315.44 ZM11.45 303.4 L9.16 300.91 L9.16 303.4 L11.45 303.4 ZM9.52 299.73 L12.53 303
|
||||
L12.53 316.49 L0 316.49 L0 299.73 L9.52 299.73 Z" class="st5"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="shape5-95" v:mID="5" v:groupContext="shape" transform="translate(107.891,-259.975)">
|
||||
<title>Sheet.5</title>
|
||||
<path d="M0 316.49 L220.83 316.49" class="st3"/>
|
||||
</g>
|
||||
<g id="group6-100" transform="translate(404.058,-88.9744)" v:mID="6" v:groupContext="group">
|
||||
<title>Sheet.6</title>
|
||||
<g id="shape49-101" v:mID="49" v:groupContext="shape">
|
||||
<title>Sheet.49</title>
|
||||
<desc>Caches the connection informations and token</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="101.945" cy="309.172" width="203.89" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="203.889" height="14.6291" class="st6"/>
|
||||
<text x="4" y="311.57" class="st7" v:langID="1036"><v:paragraph/><v:tabList/>Caches the connection informations and token</text> </g>
|
||||
<g id="shape91-104" v:mID="91" v:groupContext="shape" transform="translate(195.101,-6.31185)">
|
||||
<title>New</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M17.58 307.73 L13.07 305.96 L15 301.54 L10.56 303.46 L8.79 298.98 L7.01 303.46 L2.57 301.54 L4.5 305.96
|
||||
L0 307.73 L4.5 309.5 L2.57 313.92 L7.01 312 L8.79 316.49 L10.56 312 L15 313.92 L13.07 309.5 L17.58 307.73
|
||||
ZM9.96 310.55 C9.96 310.55 9.16 312.57 8.79 313.5 C8.42 312.57 7.62 310.55 7.62 310.55 C7.62 310.55
|
||||
5.61 311.42 4.69 311.81 C5.09 310.9 5.96 308.9 5.96 308.9 C5.96 308.9 3.93 308.1 2.99 307.73 C3.93 307.37
|
||||
5.96 306.57 5.96 306.57 C5.96 306.57 5.09 304.57 4.69 303.65 C5.61 304.05 7.62 304.92 7.62 304.92 C7.62
|
||||
304.92 8.42 302.89 8.79 301.96 C9.16 302.89 9.96 304.92 9.96 304.92 C9.96 304.92 11.96 304.05 12.89
|
||||
303.65 C12.49 304.57 11.61 306.57 11.61 306.57 C11.61 306.57 13.65 307.37 14.58 307.73 C13.65 308.1
|
||||
11.61 308.9 11.61 308.9 C11.61 308.9 12.49 310.9 12.88 311.81 C11.96 311.42 9.96 310.55 9.96 310.55
|
||||
Z" class="st5"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="shape47-106" v:mID="47" v:groupContext="shape" transform="translate(411.195,93.3904) rotate(90)">
|
||||
<title>Sheet.47</title>
|
||||
<path d="M0 316.49 L94.74 316.49" class="st3"/>
|
||||
</g>
|
||||
<g id="shape53-111" v:mID="53" v:groupContext="shape" transform="translate(38.8888,-154.814)">
|
||||
<title>Sheet.53</title>
|
||||
<desc>Browses the url returned Http://novncip:port/?token=xyz</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="58.9065" cy="303.793" width="117.82" height="25.387"/>
|
||||
<rect x="0" y="291.1" width="117.813" height="25.387" class="st6"/>
|
||||
<text x="4" y="301.39" class="st7" v:langID="1036"><v:paragraph/><v:tabList/>Browses the url returned<v:newlineChar/><tspan
|
||||
x="4" dy="1.2em" class="st13">Http</tspan>://novncip:port/?token=xyz</text> </g>
|
||||
<g id="group28-115" transform="translate(591.296,-147.811)" v:mID="28" v:groupContext="group">
|
||||
<title>Sheet.28</title>
|
||||
<g id="shape29-116" v:mID="29" v:groupContext="shape">
|
||||
<title>Sheet.29</title>
|
||||
<desc>Sends a «get_vnc_connection» message</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="89.7523" cy="309.172" width="179.51" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="179.505" height="14.6291" class="st6"/>
|
||||
<text x="24.38" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>Sends a «get_vnc_connection» message</text> </g>
|
||||
<g id="group30-119" transform="translate(174.36,-4.07806)" v:mID="30" v:groupContext="group">
|
||||
<title>Sheet.30</title>
|
||||
<g id="shape31-120" v:mID="31" v:groupContext="shape" transform="translate(0.515073,-0.812731)">
|
||||
<title>Sheet.31</title>
|
||||
<rect x="0" y="304.581" width="11.4206" height="11.9056" class="st1"/>
|
||||
</g>
|
||||
<g id="shape32-122" v:mID="32" v:groupContext="shape">
|
||||
<title>Document</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M2.41 312.82 L2.41 312.3 L10.12 312.3 L10.12 312.82 L2.41 312.82 ZM2.41 310.73 L2.41 310.2 L10.12 310.2
|
||||
L10.12 310.73 L2.41 310.73 ZM2.41 308.63 L2.41 308.11 L10.12 308.11 L10.12 308.63 L2.41 308.63 ZM2.41
|
||||
306.54 L2.41 306.01 L10.12 306.01 L10.12 306.54 L2.41 306.54 ZM2.41 304.44 L2.41 303.92 L7.25 303.92
|
||||
L7.25 304.44 L2.41 304.44 ZM11.57 315.44 L11.57 303.92 L8.68 303.92 L8.68 300.78 L0.96 300.78 L0.96
|
||||
315.44 L11.57 315.44 ZM11.45 303.4 L9.16 300.91 L9.16 303.4 L11.45 303.4 ZM9.52 299.73 L12.53 303
|
||||
L12.53 316.49 L0 316.49 L0 299.73 L9.52 299.73 Z" class="st5"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="group51-124" transform="translate(42.9672,-18.25)" v:mID="51" v:groupContext="group">
|
||||
<title>Sheet.51</title>
|
||||
<g id="group92-125" transform="translate(4.17446,-21.2904)" v:mID="92" v:groupContext="group">
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvStructureType" v:prompt="" v:val="VT4(Container)"/>
|
||||
<v:ud v:nameU="topBarHeight" v:prompt="" v:val="VT0(0):0"/>
|
||||
<v:ud v:nameU="msvSDContainerMargin" v:prompt="" v:val="VT0(0.083333333333333):29"/>
|
||||
<v:ud v:nameU="barWidth" v:prompt="" v:val="VT0(0):26"/>
|
||||
<v:ud v:nameU="barHeight" v:prompt="" v:val="VT0(0):0"/>
|
||||
<v:ud v:nameU="msvSDContainerStyle" v:prompt="" v:val="VT0(1):26"/>
|
||||
<v:ud v:nameU="msvSDContainerStyleCount" v:prompt="" v:val="VT0(5):26"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<title>Dialog form</title>
|
||||
<g id="shape92-126" v:mID="92" v:groupContext="groupContent">
|
||||
<g id="shadow92-127" v:groupContext="shadow" v:shadowOffsetX="1.8" v:shadowOffsetY="-1.8" v:shadowType="1"
|
||||
transform="matrix(1,0,0,1,1.8,1.8)" class="st14">
|
||||
<rect x="0" y="244.984" width="88.9818" height="71.5033" rx="4.5" ry="4.5" class="st15"/>
|
||||
</g>
|
||||
<rect x="0" y="244.984" width="88.9818" height="71.5033" rx="4.5" ry="4.5" class="st16"/>
|
||||
</g>
|
||||
<g id="shape96-130" v:mID="96" v:groupContext="shape" transform="translate(6,-6)">
|
||||
<title>Sheet.96</title>
|
||||
</g>
|
||||
<g id="shape97-132" v:mID="97" v:groupContext="shape" transform="translate(6,-6)">
|
||||
<title>Sheet.97</title>
|
||||
<rect x="0" y="283.784" width="76.9818" height="32.7033" class="st17"/>
|
||||
</g>
|
||||
<g id="shape98-134" v:mID="98" v:groupContext="shape" transform="translate(6,-6)">
|
||||
<title>Sheet.98</title>
|
||||
</g>
|
||||
<g id="shape100-136" v:mID="100" v:groupContext="shape" transform="translate(0,-42.0233)">
|
||||
<title>Sheet.100</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvStructureType" v:prompt="" v:val="VT4(Heading)"/>
|
||||
<v:ud v:nameU="msvSDContainerHeadingEdge" v:prompt="" v:val="VT4(Bottom)"/>
|
||||
<v:ud v:nameU="HSide" v:prompt="" v:val="VT0(0):26"/>
|
||||
</v:userDefs>
|
||||
<rect x="0" y="289.687" width="88.9818" height="26.8" rx="4.5" ry="4.5" class="st18"/>
|
||||
<rect x="0" y="289.687" width="88.9818" height="26.8" rx="4.5" ry="4.5" class="st19"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="shape50-139" v:mID="50" v:groupContext="shape">
|
||||
<title>Sheet.50</title>
|
||||
<desc>Browser</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="49.9836" cy="309.172" width="99.97" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="99.9672" height="14.6291" class="st6"/>
|
||||
<text x="36.5" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>Browser</text> </g>
|
||||
<g id="shape57-142" v:mID="57" v:groupContext="shape" transform="translate(22.7789,-29.764)">
|
||||
<title>Sheet.57</title>
|
||||
<desc>noVNC</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="27.2048" cy="306.605" width="54.41" height="19.7649"/>
|
||||
<rect x="0" y="296.722" width="54.4095" height="19.7649" class="st2"/>
|
||||
<text x="16.01" y="309" class="st20" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>noVNC</text> </g>
|
||||
</g>
|
||||
<g id="group70-145" transform="translate(154.488,-74.7093)" v:mID="70" v:groupContext="group">
|
||||
<title>Sheet.70</title>
|
||||
<g id="shape67-146" v:mID="67" v:groupContext="shape">
|
||||
<title>Sheet.67</title>
|
||||
<desc>Sends « check_token » message</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="71.1855" cy="310.322" width="142.38" height="12.3305"/>
|
||||
<rect x="0" y="304.156" width="142.371" height="12.3305" class="st6"/>
|
||||
<text x="19.13" y="312.72" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>Sends « check_token » message</text> </g>
|
||||
<g id="group60-149" transform="translate(135.34,-5.90289)" v:mID="60" v:groupContext="group">
|
||||
<v:custProps>
|
||||
<v:cp v:nameU="ShapeClass" v:lbl="ShapeClass" v:type="0" v:invis="true" v:ask="false" v:langID="1033"
|
||||
v:val="VT4(Security)"/>
|
||||
<v:cp v:nameU="ShapeType" v:lbl="ShapeType" v:type="0" v:invis="true" v:ask="false" v:langID="1033"
|
||||
v:val="VT4(Conceptual)"/>
|
||||
<v:cp v:nameU="SubShapeType" v:lbl="SubShapeType" v:type="0" v:invis="true" v:ask="false" v:langID="1033"
|
||||
v:val="VT4(Key)"/>
|
||||
</v:custProps>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="HasText" v:val="VT0(0):5"/>
|
||||
<v:ud v:nameU="ShapeClass" v:val="VT0(8):26"/>
|
||||
<v:ud v:nameU="ShapeType" v:val="VT0(7):26"/>
|
||||
<v:ud v:nameU="SubShapeType" v:val="VT0(36):26"/>
|
||||
<v:ud v:nameU="visLegendShape" v:val="VT0(2):26"/>
|
||||
<v:ud v:nameU="SolSH" v:val="VT14({BF0433D9-CD73-4EB5-8390-8653BE590246}):41"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<title>Key</title>
|
||||
<g id="shape61-150" v:mID="61" v:groupContext="shape">
|
||||
<title>Sheet.61</title>
|
||||
<path d="M2.87 316.29 L2.91 316.31 a0.0364098 0.031015 -180 0 1 -0.0368398 -0.0185307 ZM2.91 316.31 A1.58888
|
||||
1.35346 -180 0 0 4.63 316.23 A5.54577 4.72406 -180 0 0 6.01 315.12 A14.0646 11.9807 -180 0 0 7.52
|
||||
311.85 L11.13 310.1 L12.46 307.73 L16.52 305.74 L17.58 303.94 L17.58 302.35 L16.29 301.73 L7.23
|
||||
306.22 A2.02885 1.72824 -180 0 0 6.95 305.77 A1.74485 1.48631 -180 0 0 6.16 305.17 A1.74485 1.48631
|
||||
-180 0 0 4.87 305.13 A1.68344 1.43401 0 0 1 6.16 305.17 L5.48 304.81 A2.18877 1.86446 0 0 0 3.34
|
||||
304.59 A6.21394 5.29322 0 0 0 1.27 306.94 A15.1992 12.9471 0 0 0 0 311.78 A8.14148 6.93517 0 0 0
|
||||
1.29 315.53 L2.9 316.32 L2.91 316.31 ZM1.29 312.4 A15.3993 13.1176 -180 0 1 2.24 308.19 A17.2407
|
||||
14.6862 -180 0 0 1.29 312.4 A8.18363 6.97106 -180 0 0 1.81 314.87 A6.38792 5.44143 -180 0 1 1.29
|
||||
312.4 Z" class="st8"/>
|
||||
<path d="M2.87 316.29 L2.91 316.31 a0.0364098 0.031015 -180 0 1 -0.0368398 -0.0185307M2.91 316.31 A1.58888 1.35346
|
||||
-180 0 0 4.63 316.23 A5.54577 4.72406 -180 0 0 6.01 315.12 A14.0646 11.9807 -180 0 0 7.52 311.85
|
||||
L11.13 310.1 L12.46 307.73 L16.52 305.74 L17.58 303.94 L17.58 302.35 L16.29 301.73 L7.23 306.22
|
||||
A2.02885 1.72824 -180 0 0 6.95 305.77 A1.74485 1.48631 -180 0 0 6.16 305.17 A1.74485 1.48631 -180
|
||||
0 0 4.87 305.13 A1.68344 1.43401 0 0 1 6.16 305.17 L5.48 304.81 A2.18877 1.86446 0 0 0 3.34 304.59
|
||||
A6.21394 5.29322 0 0 0 1.27 306.94 A15.1992 12.9471 0 0 0 0 311.78 A8.14148 6.93517 0 0 0 1.29 315.53
|
||||
L2.9 316.32M1.29 312.4 A15.3993 13.1176 -180 0 1 2.24 308.19 A17.2407 14.6862 -180 0 0 1.29 312.4
|
||||
A8.18363 6.97106 -180 0 0 1.81 314.87 A6.38792 5.44143 -180 0 1 1.29 312.4" class="st9"/>
|
||||
</g>
|
||||
<g id="shape62-153" v:mID="62" v:groupContext="shape" transform="translate(1.29363,0)">
|
||||
<title>Sheet.62</title>
|
||||
<path d="M16.28 302.35 L16.28 303.94 L15.23 305.74 L11.17 307.73 L9.83 310.1 L6.23 311.85 A14.0646 11.9807 0
|
||||
0 1 4.72 315.12 A5.54577 4.72406 0 0 1 3.34 316.23 A1.58888 1.35346 0 0 1 1 315.77 A8.18363 6.97106
|
||||
0 0 1 0 312.4 A17.2407 14.6862 0 0 1 0.99 308.07 A7.30166 6.21978 0 0 1 3.34 305.21 A1.74485 1.48631
|
||||
0 0 1 5.65 305.77 A4.64183 3.95405 0 0 1 6.38 307.23 L16.28 302.35 Z" class="st10"/>
|
||||
</g>
|
||||
<g id="shape63-156" v:mID="63" v:groupContext="shape" transform="translate(57.0963,1.05913) rotate(10)">
|
||||
<title>Sheet.63</title>
|
||||
<ellipse cx="0.975458" cy="314.855" rx="0.975458" ry="1.63145" class="st11"/>
|
||||
<ellipse cx="0.975458" cy="314.855" rx="0.975458" ry="1.63145" class="st12"/>
|
||||
</g>
|
||||
<g id="shape64-160" v:mID="64" v:groupContext="shape" transform="translate(7.23295,-9.25961)">
|
||||
<title>Sheet.64</title>
|
||||
<path d="M0 315.48 L0.44 316.49 L10.34 311.61 L9.05 310.99 L0 315.48 Z" class="st10"/>
|
||||
</g>
|
||||
<g id="shape65-163" v:mID="65" v:groupContext="shape" transform="translate(0,-0.168722)">
|
||||
<title>Sheet.65</title>
|
||||
<path d="M2.9 316.49 A6.38792 5.44143 0 0 1 1.29 312.57 A15.3993 13.1176 0 0 1 2.29 308.23 A8.18314 6.97065 0
|
||||
0 1 4.63 305.39 A1.68344 1.43401 0 0 1 6.16 305.34 L5.48 304.97 A2.18877 1.86446 -180 0 0 3.34 304.76
|
||||
A6.21394 5.29322 -180 0 0 1.27 307.1 A15.1992 12.9471 -180 0 0 0 311.95 A8.14148 6.93517 -180 0
|
||||
0 1.29 315.69 L2.9 316.49 Z" class="st10"/>
|
||||
</g>
|
||||
<g id="shape66-166" v:mID="66" v:groupContext="shape" transform="translate(2.55263,-3.58912)">
|
||||
<title>Sheet.66</title>
|
||||
<path d="M0.76 314.17 A3.52228 3.00038 0 0 1 0 316.09 a0.626726 0.533865 -180 0 0 0.946178 0.306395 A1.85316
|
||||
1.57858 -180 0 0 1.62 315.56 A3.64133 3.1018 -180 0 0 1.79 313.94 a0.88788 0.756324 -180 0 0 -0.643292
|
||||
-0.655002 a0.935131 0.796573 -180 0 0 -0.595176 0.204816 A3.2863 2.79937 0 0 1 0.76 314.17 Z"
|
||||
class="st10"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g id="shape71-169" v:mID="71" v:groupContext="shape" transform="translate(54.7449,-82.2047)">
|
||||
<title>Internet</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M11.84 293.18 A11.8415 11.655 -180 0 0 0 304.83 A11.841 11.6545 -180 0 0 11.84 316.49 A11.8405 11.654 -180 0
|
||||
0 23.68 304.83 A11.841 11.6545 -180 0 0 11.84 293.18 ZM12.21 315.01 L12.21 314.63 L12.21 310.3 L16.21 310.3
|
||||
L15.96 310.82 A13.3821 13.1713 0 0 1 13.37 314.41 L12.98 314.77 L12.73 314.99 L12.21 315.01 ZM12.6 294.67
|
||||
L12.83 294.87 A13.4054 13.1943 0 0 1 15.87 298.84 L16.14 299.37 L12.21 299.37 L12.21 294.65 L12.6 294.67
|
||||
ZM20.58 299.37 L16.95 299.37 L16.85 299.15 A14.1999 13.9762 -180 0 0 14.28 295.25 L13.89 294.84 A10.3822
|
||||
10.2187 0 0 1 20.58 299.37 ZM12.21 304.47 L12.21 300.1 L16.43 300.1 L16.52 300.34 A13.9247 13.7054 0 0 1
|
||||
17.29 304.09 L17.31 304.47 L12.21 304.47 L12.21 304.47 ZM17.32 305.2 L17.3 305.58 A13.8413 13.6233 0 0 1
|
||||
16.58 309.32 L16.49 309.57 L12.21 309.57 L12.21 305.2 L17.32 305.2 ZM14.4 314.39 A14.1216 13.8992 -180 0
|
||||
0 16.9 310.52 L16.99 310.3 L20.58 310.3 A10.3818 10.2183 0 0 1 14.03 314.8 L14.4 314.39 ZM17.28 309.57 L17.43
|
||||
309.1 A14.6141 14.3839 -180 0 0 18.05 305.55 L18.06 305.2 L22.18 305.2 A10.2928 10.1307 0 0 1 21.01 309.57
|
||||
L17.28 309.57 ZM18.06 304.47 L18.04 304.13 A14.6934 14.462 -180 0 0 17.39 300.57 L17.24 300.1 L21.01 300.1
|
||||
A10.2766 10.1148 0 0 1 22.18 304.47 L18.06 304.47 ZM11.47 295.18 L11.47 299.37 L7.55 299.37 L7.81 298.84
|
||||
A13.4428 13.2311 0 0 1 10.34 295.36 L10.35 295.36 L10.34 295.36 L10.7 295.04 L11.12 294.67 L11.47 294.65
|
||||
L11.47 295.18 ZM9.84 294.83 L9.45 295.24 A14.16 13.937 -180 0 0 6.87 299.15 L6.77 299.37 L3.11 299.37 A10.3778
|
||||
10.2144 0 0 1 9.84 294.83 ZM6.48 300.1 L6.33 300.57 A14.6113 14.3812 -180 0 0 5.68 304.13 L5.66 304.47 L1.5
|
||||
304.47 A10.2869 10.1249 0 0 1 2.67 300.1 L6.48 300.1 ZM1.5 305.2 L5.66 305.2 L5.67 305.55 A14.5258 14.297
|
||||
-180 0 0 6.29 309.1 L6.44 309.57 L2.67 309.57 A10.2922 10.1301 0 0 1 1.5 305.2 ZM6.72 310.3 L6.82 310.52
|
||||
A14.1361 13.9135 -180 0 0 9.33 314.41 L9.7 314.81 A10.384 10.2205 0 0 1 3.11 310.3 L6.72 310.3 L6.72 310.3
|
||||
ZM7.16 309.32 A13.9094 13.6904 0 0 1 6.42 305.59 L6.4 305.2 L11.47 305.2 L11.47 309.57 L7.24 309.57 L7.16
|
||||
309.32 ZM6.4 304.47 L6.42 304.09 A13.8139 13.5964 0 0 1 7.18 300.34 L7.27 300.1 L11.47 300.1 L11.47 304.47
|
||||
L6.4 304.47 ZM10.99 314.99 L10.85 314.86 A13.4678 13.2557 0 0 1 7.79 310.82 L7.53 310.29 L11.47 310.29 L11.47
|
||||
315.01 L10.99 314.99 Z" class="st5"/>
|
||||
</g>
|
||||
<g id="shape72-171" v:mID="72" v:groupContext="shape" transform="translate(311.536,553.169) rotate(180)">
|
||||
<title>Sheet.72</title>
|
||||
<path d="M0 316.49 L24.74 292.93 L148.52 292.93" class="st3"/>
|
||||
</g>
|
||||
<g id="group83-176" transform="translate(193.428,-49.3228)" v:mID="83" v:groupContext="group">
|
||||
<title>Sheet.83</title>
|
||||
<g id="shape74-177" v:mID="74" v:groupContext="shape">
|
||||
<title>Sheet.74</title>
|
||||
<desc>Proxy starts</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="29.2217" cy="309.172" width="58.45" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="58.4434" height="14.6291" class="st6"/>
|
||||
<text x="4" y="311.57" class="st7" v:langID="1036"><v:paragraph/><v:tabList/>Proxy starts</text> </g>
|
||||
<g id="shape79-180" v:mID="79" v:groupContext="shape" transform="translate(53.1704,-7.69048)">
|
||||
<title>Power</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M8.57 303.69 L8.57 305.68 A4.76463 4.67134 0 0 1 11.43 309.95 A4.76568 4.67237 0 0 1 6.67 314.62 A4.7667
|
||||
4.67337 0 0 1 1.9 309.95 A4.76436 4.67108 0 0 1 4.76 305.68 L4.76 303.7 A6.66222 6.53178 -180 0 0 0
|
||||
309.95 A6.66572 6.53521 -180 0 0 6.67 316.49 A6.66572 6.53521 -180 0 0 13.33 309.95 A6.66245 6.532 -180
|
||||
0 0 8.57 303.69 ZM5.71 311.35 L7.62 311.35 L7.62 302.48 L5.71 302.48 L5.71 311.35 Z" class="st5"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="shape102-182" v:mID="102" v:groupContext="shape" transform="translate(304.228,373.162) rotate(180)">
|
||||
<title>Sheet.102</title>
|
||||
<path d="M0 316.49 L24.74 292.93 L160.58 292.93 L167.44 292.93" class="st3"/>
|
||||
</g>
|
||||
<g id="shape106-187" v:mID="106" v:groupContext="shape" transform="translate(416.753,-254.409)">
|
||||
<title>Sheet.106</title>
|
||||
<desc>2</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="4.19166" cy="309.432" width="8.39" height="14.1096"/>
|
||||
<rect x="0" y="302.377" width="8.38332" height="14.1096" class="st1"/>
|
||||
<text x="0" y="314.83" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>2</text> </g>
|
||||
<g id="shape107-190" v:mID="107" v:groupContext="shape" transform="translate(581.386,-147.402)">
|
||||
<title>Sheet.107</title>
|
||||
<desc>3</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="4.25197" cy="308.55" width="8.51" height="15.874"/>
|
||||
<rect x="0" y="300.613" width="8.50394" height="15.874" class="st1"/>
|
||||
<text x="0" y="313.95" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>3</text> </g>
|
||||
<g id="shape108-193" v:mID="108" v:groupContext="shape" transform="translate(293.74,-159.307)">
|
||||
<title>Sheet.108</title>
|
||||
<desc>4</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="4.46457" cy="309.259" width="8.93" height="14.4567"/>
|
||||
<rect x="0" y="302.03" width="8.92913" height="14.4567" class="st1"/>
|
||||
<text x="0" y="314.66" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>4</text> </g>
|
||||
<g id="group105-196" transform="translate(153.071,-229.291)" v:mID="105" v:groupContext="group">
|
||||
<title>Sheet.105</title>
|
||||
<g id="shape104-197" v:mID="104" v:groupContext="shape">
|
||||
<title>Sheet.104</title>
|
||||
<desc>Returns a url with a token</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="53.8583" cy="309.172" width="107.72" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="107.717" height="14.6291" class="st6"/>
|
||||
<text x="4" y="311.57" class="st7" v:langID="1036"><v:paragraph/><v:tabList/>Returns a url with a token</text> </g>
|
||||
<g id="shape1-200" v:mID="1" v:groupContext="shape" transform="translate(95.8617,-8.53134)">
|
||||
<title>Link.84</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M21.2 310.42 A1.35348 1.37513 0 0 1 19.84 311.79 L9.02 311.79 A1.35348 1.37513 0 0 1 7.67 310.42 A1.35348
|
||||
1.37513 0 0 1 9.02 309.04 L19.84 309.04 A1.35348 1.37513 0 0 1 21.2 310.42 ZM18.29 312.82 A1.7981 1.82687
|
||||
-180 0 0 19.84 313.74 L24.35 313.74 A1.80579 1.83468 -180 0 0 26.16 311.9 L26.16 309.16 A1.80521 1.8341
|
||||
-180 0 0 24.35 307.32 L19.84 307.32 A1.7981 1.82687 -180 0 0 18.29 308.24 L15.42 308.24 A4.51125 4.58343
|
||||
0 0 1 19.84 304.57 L24.35 304.57 A4.50985 4.58201 0 0 1 28.86 309.16 L28.86 311.9 A4.50985 4.58201 0
|
||||
0 1 24.35 316.49 L19.84 316.49 A4.51051 4.58268 0 0 1 15.42 312.82 L18.29 312.82 ZM10.57 312.82 A1.7981
|
||||
1.82687 0 0 1 9.02 313.74 L4.51 313.74 A1.80579 1.83468 0 0 1 2.71 311.9 L2.71 309.16 A1.80521 1.8341
|
||||
0 0 1 4.51 307.32 L9.02 307.32 A1.7981 1.82687 0 0 1 10.57 308.24 L13.44 308.24 A4.51224 4.58443 -180
|
||||
0 0 9.02 304.57 L4.51 304.57 A4.50985 4.58201 -180 0 0 0 309.16 L0 311.9 A4.50985 4.58201 -180 0 0 4.51
|
||||
316.49 L9.02 316.49 A4.51051 4.58268 -180 0 0 13.44 312.82 L10.57 312.82 Z" class="st5"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="group109-202" transform="translate(166.773,-252.66)" v:mID="109" v:groupContext="group">
|
||||
<title>Sheet.109</title>
|
||||
<g id="shape43-203" v:mID="43" v:groupContext="shape">
|
||||
<title>Sheet.43</title>
|
||||
<desc>The user requests an access URL</desc>
|
||||
<v:textBlock v:margins="rect(4,4,4,4)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="62.3971" cy="309.172" width="124.8" height="14.6291"/>
|
||||
<rect x="0" y="301.858" width="124.794" height="14.6291" class="st6"/>
|
||||
<text x="9.88" y="311.57" class="st7" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>The user requests an access URL</text> </g>
|
||||
<g id="shape103-206" v:mID="103" v:groupContext="shape" transform="translate(113.857,-9.31811)">
|
||||
<title>Internet.103</title>
|
||||
<v:userDefs>
|
||||
<v:ud v:nameU="msvShapeCategories" v:prompt="" v:val="VT4(Icon)"/>
|
||||
<v:ud v:nameU="visVersion" v:prompt="" v:val="VT0(14):26"/>
|
||||
</v:userDefs>
|
||||
<path d="M8.76 299.25 A8.7555 8.61762 -180 0 0 0 307.87 A8.75515 8.61727 -180 0 0 8.76 316.49 A8.7548 8.61693 -180
|
||||
0 0 17.51 307.87 A8.75515 8.61727 -180 0 0 8.76 299.25 ZM9.03 315.4 L9.03 315.12 L9.03 311.91 L11.99
|
||||
311.91 L11.8 312.3 A9.89464 9.73881 0 0 1 9.89 314.95 L9.6 315.22 L9.41 315.38 L9.03 315.4 ZM9.32 300.36
|
||||
L9.48 300.51 A9.9119 9.75581 0 0 1 11.73 303.44 L11.93 303.83 L9.03 303.83 L9.03 300.34 L9.32 300.36
|
||||
ZM15.21 303.83 L12.53 303.83 L12.46 303.67 A10.4993 10.334 -180 0 0 10.56 300.79 L10.27 300.48 A7.67653
|
||||
7.55564 0 0 1 15.21 303.83 ZM9.03 307.6 L9.03 304.37 L12.15 304.37 L12.22 304.55 A10.2958 10.1337 0
|
||||
0 1 12.78 307.32 L12.8 307.6 L9.03 307.6 L9.03 307.6 ZM12.81 308.14 L12.79 308.42 A10.2341 10.073 0
|
||||
0 1 12.26 311.19 L12.19 311.37 L9.03 311.37 L9.03 308.14 L12.81 308.14 ZM10.65 314.94 A10.4414 10.277
|
||||
-180 0 0 12.49 312.07 L12.57 311.91 L15.21 311.91 A7.67625 7.55536 0 0 1 10.37 315.24 L10.65 314.94
|
||||
ZM12.78 311.37 L12.88 311.02 A10.8055 10.6354 -180 0 0 13.34 308.4 L13.36 308.14 L16.4 308.14 A7.61043
|
||||
7.49058 0 0 1 15.53 311.37 L12.78 311.37 ZM13.35 307.6 L13.34 307.35 A10.8642 10.6931 -180 0 0 12.86
|
||||
304.72 L12.75 304.37 L15.53 304.37 A7.59845 7.47879 0 0 1 16.4 307.6 L13.35 307.6 ZM8.48 300.73 L8.48
|
||||
303.83 L5.58 303.83 L5.78 303.44 A9.93954 9.78301 0 0 1 7.65 300.87 L7.65 300.86 L7.65 300.87 L7.91
|
||||
300.63 L8.22 300.36 L8.48 300.34 L8.48 300.73 ZM7.27 300.47 L6.99 300.78 A10.4698 10.3049 -180 0 0 5.08
|
||||
303.67 L5.01 303.83 L2.3 303.83 A7.6733 7.55246 0 0 1 7.27 300.47 ZM4.79 304.37 L4.68 304.72 A10.8035
|
||||
10.6334 -180 0 0 4.2 307.35 L4.18 307.6 L1.11 307.6 A7.60608 7.4863 0 0 1 1.98 304.37 L4.79 304.37 ZM1.11
|
||||
308.14 L4.18 308.14 L4.19 308.4 A10.7403 10.5711 -180 0 0 4.65 311.02 L4.76 311.37 L1.98 311.37 A7.60995
|
||||
7.49011 0 0 1 1.11 308.14 ZM4.97 311.91 L5.04 312.07 A10.4522 10.2876 -180 0 0 6.9 314.95 L7.17 315.25
|
||||
A7.67788 7.55697 0 0 1 2.3 311.91 L4.97 311.91 L4.97 311.91 ZM5.29 311.19 A10.2845 10.1226 0 0 1 4.75
|
||||
308.43 L4.73 308.14 L8.48 308.14 L8.48 311.37 L5.36 311.37 L5.29 311.19 ZM4.73 307.6 L4.75 307.32 A10.2139
|
||||
10.0531 0 0 1 5.31 304.55 L5.37 304.37 L8.48 304.37 L8.48 307.6 L4.73 307.6 ZM8.12 315.38 L8.02 315.29
|
||||
A9.95803 9.80121 0 0 1 5.76 312.3 L5.57 311.91 L8.48 311.91 L8.48 315.4 L8.12 315.38 Z" class="st5"/>
|
||||
</g>
|
||||
</g>
|
||||
<g id="shape101-208" v:mID="101" v:groupContext="shape" transform="translate(156.472,-253.63)">
|
||||
<title>Sheet.101</title>
|
||||
<desc>1</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="4.25197" cy="310.463" width="8.51" height="12.0472"/>
|
||||
<rect x="0" y="304.44" width="8.50394" height="12.0472" class="st1"/>
|
||||
<text x="0" y="315.86" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>1</text> </g>
|
||||
<g id="shape110-211" v:mID="110" v:groupContext="shape" transform="translate(143.433,-230.811)">
|
||||
<title>Sheet.110</title>
|
||||
<desc>5</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="4.25197" cy="310.322" width="8.51" height="12.3307"/>
|
||||
<rect x="0" y="304.156" width="8.50394" height="12.3307" class="st1"/>
|
||||
<text x="0" y="315.72" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>5</text> </g>
|
||||
<g id="shape111-214" v:mID="111" v:groupContext="shape" transform="translate(26.9291,-160.157)">
|
||||
<title>Sheet.111</title>
|
||||
<desc>6</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="5.17323" cy="309.259" width="10.35" height="14.4567"/>
|
||||
<rect x="0" y="302.03" width="10.3465" height="14.4567" class="st1"/>
|
||||
<text x="0.61" y="314.66" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>6</text> </g>
|
||||
<g id="shape112-217" v:mID="112" v:groupContext="shape" transform="translate(144.213,-74.4094)">
|
||||
<title>Sheet.112</title>
|
||||
<desc>7</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="4.42913" cy="309.259" width="8.86" height="14.4567"/>
|
||||
<rect x="0" y="302.03" width="8.85827" height="14.4567" class="st1"/>
|
||||
<text x="0" y="314.66" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>7</text> </g>
|
||||
<g id="shape113-220" v:mID="113" v:groupContext="shape" transform="translate(183.969,-49.3762)">
|
||||
<title>Sheet.113</title>
|
||||
<desc>8</desc>
|
||||
<v:textBlock v:margins="rect(0,0,0,0)" v:tabSpace="42.5197"/>
|
||||
<v:textRect cx="4.2874" cy="309.542" width="8.58" height="13.8898"/>
|
||||
<rect x="0" y="302.597" width="8.5748" height="13.8898" class="st1"/>
|
||||
<text x="0" y="314.94" class="st21" v:langID="1036"><v:paragraph v:horizAlign="1"/><v:tabList/>8</text> </g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
|
@ -0,0 +1,529 @@
|
|||
=======
|
||||
Flavors
|
||||
=======
|
||||
|
||||
Admin users can use the :command:`openstack flavor` command to customize and
|
||||
manage flavors. To see information for this command, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor --help
|
||||
Command "flavor" matches:
|
||||
flavor create
|
||||
flavor delete
|
||||
flavor list
|
||||
flavor set
|
||||
flavor show
|
||||
flavor unset
|
||||
|
||||
.. note::
|
||||
|
||||
- Configuration rights can be delegated to additional users by redefining
|
||||
the access controls for ``compute_extension:flavormanage`` in
|
||||
``/etc/nova/policy.json`` on the ``nova-api`` server.
|
||||
|
||||
- The Dashboard simulates the ability to modify a flavor by deleting an
|
||||
existing flavor and creating a new one with the same name.
|
||||
|
||||
Flavors define these elements:
|
||||
|
||||
.. todo:: This would be much easier to read as a list-table or similar
|
||||
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| Element | Description |
|
||||
+=============+===============================================================+
|
||||
| Name | A descriptive name. XX.SIZE_NAME is typically not required, |
|
||||
| | though some third party tools may rely on it. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| Memory MB | Instance memory in megabytes. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| Disk | Virtual root disk size in gigabytes. This is an ephemeral di\ |
|
||||
| | sk that the base image is copied into. When booting from a p\ |
|
||||
| | ersistent volume it is not used. The "0" size is a special c\ |
|
||||
| | ase which uses the native base image size as the size of the |
|
||||
| | ephemeral root volume. However, in this case the filter |
|
||||
| | scheduler cannot select the compute host based on the virtual |
|
||||
| | image size. Therefore 0 should only be used for volume booted |
|
||||
| | instances or for testing purposes. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| Ephemeral | Specifies the size of a secondary ephemeral data disk. This |
|
||||
| | is an empty, unformatted disk and exists only for the life o\ |
|
||||
| | f the instance. Default value is ``0``. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| Swap | Optional swap space allocation for the instance. Default |
|
||||
| | value is ``0``. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| VCPUs | Number of virtual CPUs presented to the instance. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| RXTX Factor | Optional property allows created servers to have a different |
|
||||
| | bandwidth cap than that defined in the network they are att\ |
|
||||
| | ached to. This factor is multiplied by the rxtx_base propert\ |
|
||||
| | y of the network. Default value is ``1.0``. That is, the same |
|
||||
| | as attached network. This parameter is only available for Xen |
|
||||
| | or NSX based systems. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| Is Public | Boolean value, whether flavor is available to all users or p\ |
|
||||
| | rivate to the project it was created in. Defaults to ``True``.|
|
||||
+-------------+---------------------------------------------------------------+
|
||||
| Extra Specs | Key and value pairs that define on which compute nodes a fla\ |
|
||||
| | vor can run. These pairs must match corresponding pairs on t\ |
|
||||
| | he compute nodes. Use to implement special resources, such a\ |
|
||||
| | s flavors that run on only compute nodes with GPU hardware. |
|
||||
+-------------+---------------------------------------------------------------+
|
||||
|
||||
.. note::
|
||||
|
||||
Flavor customization can be limited by the hypervisor in use. For example
|
||||
the libvirt driver enables quotas on CPUs available to a VM, disk tuning,
|
||||
bandwidth I/O, watchdog behavior, random number generator device control,
|
||||
and instance VIF traffic control.
|
||||
|
||||
Is Public
|
||||
~~~~~~~~~
|
||||
|
||||
Flavors can be assigned to particular projects. By default, a flavor is public
|
||||
and available to all projects. Private flavors are only accessible to those on
|
||||
the access list and are invisible to other projects. To create and assign a
|
||||
private flavor to a project, run this command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor create --private p1.medium --id auto --ram 512 --disk 40 --vcpus 4
|
||||
|
||||
Extra Specs
|
||||
~~~~~~~~~~~
|
||||
|
||||
CPU limits
|
||||
You can configure the CPU limits with control parameters with the ``nova``
|
||||
client. For example, to configure the I/O limit, use:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property quota:read_bytes_sec=10240000 \
|
||||
--property quota:write_bytes_sec=10240000
|
||||
|
||||
Use these optional parameters to control weight shares, enforcement intervals
|
||||
for runtime quotas, and a quota for maximum allowed bandwidth:
|
||||
|
||||
- ``cpu_shares``: Specifies the proportional weighted share for the domain.
|
||||
If this element is omitted, the service defaults to the OS provided
|
||||
defaults. There is no unit for the value; it is a relative measure based on
|
||||
the setting of other VMs. For example, a VM configured with value 2048 gets
|
||||
twice as much CPU time as a VM configured with value 1024.
|
||||
|
||||
- ``cpu_shares_level``: On VMware, specifies the allocation level. Can be
|
||||
``custom``, ``high``, ``normal``, or ``low``. If you choose ``custom``, set
|
||||
the number of shares using ``cpu_shares_share``.
|
||||
|
||||
- ``cpu_period``: Specifies the enforcement interval (unit: microseconds)
|
||||
for QEMU and LXC hypervisors. Within a period, each VCPU of the domain is
|
||||
not allowed to consume more than the quota worth of runtime. The value
|
||||
should be in range ``[1000, 1000000]``. A period with value 0 means no
|
||||
value.
|
||||
|
||||
- ``cpu_limit``: Specifies the upper limit for VMware machine CPU allocation
|
||||
in MHz. This parameter ensures that a machine never uses more than the
|
||||
defined amount of CPU time. It can be used to enforce a limit on the
|
||||
machine's CPU performance.
|
||||
|
||||
- ``cpu_reservation``: Specifies the guaranteed minimum CPU reservation in
|
||||
MHz for VMware. This means that if needed, the machine will definitely get
|
||||
allocated the reserved amount of CPU cycles.
|
||||
|
||||
- ``cpu_quota``: Specifies the maximum allowed bandwidth (unit:
|
||||
microseconds). A domain with a negative-value quota indicates that the
|
||||
domain has infinite bandwidth, which means that it is not bandwidth
|
||||
controlled. The value should be in range ``[1000, 18446744073709551]`` or
|
||||
less than 0. A quota with value 0 means no value. You can use this feature
|
||||
to ensure that all vCPUs run at the same speed. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property quota:cpu_quota=10000 \
|
||||
--property quota:cpu_period=20000
|
||||
|
||||
In this example, an instance of ``FLAVOR-NAME`` can only consume a maximum
|
||||
of 50% CPU of a physical CPU computing capability.
|
||||
|
||||
Memory limits
|
||||
For VMware, you can configure the memory limits with control parameters.
|
||||
|
||||
Use these optional parameters to limit the memory allocation, guarantee
|
||||
minimum memory reservation, and to specify shares used in case of resource
|
||||
contention:
|
||||
|
||||
- ``memory_limit``: Specifies the upper limit for VMware machine memory
|
||||
allocation in MB. The utilization of a virtual machine will not exceed this
|
||||
limit, even if there are available resources. This is typically used to
|
||||
ensure a consistent performance of virtual machines independent of
|
||||
available resources.
|
||||
|
||||
- ``memory_reservation``: Specifies the guaranteed minimum memory reservation
|
||||
in MB for VMware. This means the specified amount of memory will definitely
|
||||
be allocated to the machine.
|
||||
|
||||
- ``memory_shares_level``: On VMware, specifies the allocation level. This
|
||||
can be ``custom``, ``high``, ``normal`` or ``low``. If you choose
|
||||
``custom``, set the number of shares using ``memory_shares_share``.
|
||||
|
||||
- ``memory_shares_share``: Specifies the number of shares allocated in the
|
||||
event that ``custom`` is used. There is no unit for this value. It is a
|
||||
relative measure based on the settings for other VMs. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property quota:memory_shares_level=custom \
|
||||
--property quota:memory_shares_share=15
|
||||
|
||||
Disk I/O limits
|
||||
For VMware, you can configure the resource limits for disk with control
|
||||
parameters.
|
||||
|
||||
Use these optional parameters to limit the disk utilization, guarantee disk
|
||||
allocation, and to specify shares used in case of resource contention. This
|
||||
allows the VMware driver to enable disk allocations for the running instance.
|
||||
|
||||
- ``disk_io_limit``: Specifies the upper limit for disk utilization in I/O
|
||||
per second. The utilization of a virtual machine will not exceed this
|
||||
limit, even if there are available resources. The default value is -1 which
|
||||
indicates unlimited usage.
|
||||
|
||||
- ``disk_io_reservation``: Specifies the guaranteed minimum disk allocation
|
||||
in terms of Input/output Operations Per Second (IOPS).
|
||||
|
||||
- ``disk_io_shares_level``: Specifies the allocation level. This can be
|
||||
``custom``, ``high``, ``normal`` or ``low``. If you choose custom, set the
|
||||
number of shares using ``disk_io_shares_share``.
|
||||
|
||||
- ``disk_io_shares_share``: Specifies the number of shares allocated in the
|
||||
event that ``custom`` is used. When there is resource contention, this
|
||||
value is used to determine the resource allocation.
|
||||
|
||||
The example below sets the ``disk_io_reservation`` to 2000 IOPS.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property quota:disk_io_reservation=2000
|
||||
|
||||
Disk tuning
|
||||
Using disk I/O quotas, you can set maximum disk write to 10 MB per second for
|
||||
a VM user. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property quota:disk_write_bytes_sec=10485760
|
||||
|
||||
The disk I/O options are:
|
||||
|
||||
- ``disk_read_bytes_sec``
|
||||
- ``disk_read_iops_sec``
|
||||
- ``disk_write_bytes_sec``
|
||||
- ``disk_write_iops_sec``
|
||||
- ``disk_total_bytes_sec``
|
||||
- ``disk_total_iops_sec``
|
||||
|
||||
Bandwidth I/O
|
||||
The vif I/O options are:
|
||||
|
||||
- ``vif_inbound_average``
|
||||
- ``vif_inbound_burst``
|
||||
- ``vif_inbound_peak``
|
||||
- ``vif_outbound_average``
|
||||
- ``vif_outbound_burst``
|
||||
- ``vif_outbound_peak``
|
||||
|
||||
Incoming and outgoing traffic can be shaped independently. The bandwidth
|
||||
element can have at most, one inbound and at most, one outbound child
|
||||
element. If you leave any of these child elements out, no quality of service
|
||||
(QoS) is applied on that traffic direction. So, if you want to shape only the
|
||||
network's incoming traffic, use inbound only (and vice versa). Each element
|
||||
has one mandatory attribute average, which specifies the average bit rate on
|
||||
the interface being shaped.
|
||||
|
||||
There are also two optional attributes (integer): ``peak``, which specifies
|
||||
the maximum rate at which a bridge can send data (kilobytes/second), and
|
||||
``burst``, the amount of bytes that can be burst at peak speed (kilobytes).
|
||||
The rate is shared equally within domains connected to the network.
|
||||
|
||||
The example below sets network traffic bandwidth limits for existing flavor
|
||||
as follows:
|
||||
|
||||
- Outbound traffic:
|
||||
|
||||
- average: 262 Mbps (32768 kilobytes/second)
|
||||
|
||||
- peak: 524 Mbps (65536 kilobytes/second)
|
||||
|
||||
- burst: 65536 kilobytes
|
||||
|
||||
- Inbound traffic:
|
||||
|
||||
- average: 262 Mbps (32768 kilobytes/second)
|
||||
|
||||
- peak: 524 Mbps (65536 kilobytes/second)
|
||||
|
||||
- burst: 65536 kilobytes
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property quota:vif_outbound_average=32768 \
|
||||
--property quota:vif_outbound_peak=65536 \
|
||||
--property quota:vif_outbound_burst=65536 \
|
||||
--property quota:vif_inbound_average=32768 \
|
||||
--property quota:vif_inbound_peak=65536 \
|
||||
--property quota:vif_inbound_burst=65536
|
||||
|
||||
.. note::
|
||||
|
||||
All the speed limit values in above example are specified in
|
||||
kilobytes/second. And burst values are in kilobytes. Values were converted
|
||||
using 'Data rate units on Wikipedia
|
||||
<https://en.wikipedia.org/wiki/Data_rate_units>`_.
|
||||
|
||||
Watchdog behavior
|
||||
For the libvirt driver, you can enable and set the behavior of a virtual
|
||||
hardware watchdog device for each flavor. Watchdog devices keep an eye on the
|
||||
guest server, and carry out the configured action, if the server hangs. The
|
||||
watchdog uses the i6300esb device (emulating a PCI Intel 6300ESB). If
|
||||
``hw:watchdog_action`` is not specified, the watchdog is disabled.
|
||||
|
||||
To set the behavior, use:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME --property hw:watchdog_action=ACTION
|
||||
|
||||
Valid ACTION values are:
|
||||
|
||||
- ``disabled``: (default) The device is not attached.
|
||||
- ``reset``: Forcefully reset the guest.
|
||||
- ``poweroff``: Forcefully power off the guest.
|
||||
- ``pause``: Pause the guest.
|
||||
- ``none``: Only enable the watchdog; do nothing if the server hangs.
|
||||
|
||||
.. note::
|
||||
|
||||
Watchdog behavior set using a specific image's properties will override
|
||||
behavior set using flavors.
|
||||
|
||||
Random-number generator
|
||||
If a random-number generator device has been added to the instance through
|
||||
its image properties, the device can be enabled and configured using:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property hw_rng:allowed=True \
|
||||
--property hw_rng:rate_bytes=RATE-BYTES \
|
||||
--property hw_rng:rate_period=RATE-PERIOD
|
||||
|
||||
Where:
|
||||
|
||||
- RATE-BYTES: (integer) Allowed amount of bytes that the guest can read from
|
||||
the host's entropy per period.
|
||||
- RATE-PERIOD: (integer) Duration of the read period in seconds.
|
||||
|
||||
CPU topology
|
||||
For the libvirt driver, you can define the topology of the processors in the
|
||||
virtual machine using properties. The properties with ``max`` limit the
|
||||
number that can be selected by the user with image properties.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property hw:cpu_sockets=FLAVOR-SOCKETS \
|
||||
--property hw:cpu_cores=FLAVOR-CORES \
|
||||
--property hw:cpu_threads=FLAVOR-THREADS \
|
||||
--property hw:cpu_max_sockets=FLAVOR-SOCKETS \
|
||||
--property hw:cpu_max_cores=FLAVOR-CORES \
|
||||
--property hw:cpu_max_threads=FLAVOR-THREADS
|
||||
|
||||
Where:
|
||||
|
||||
- FLAVOR-SOCKETS: (integer) The number of sockets for the guest VM. By
|
||||
default, this is set to the number of vCPUs requested.
|
||||
- FLAVOR-CORES: (integer) The number of cores per socket for the guest VM. By
|
||||
default, this is set to ``1``.
|
||||
- FLAVOR-THREADS: (integer) The number of threads per core for the guest VM.
|
||||
By default, this is set to ``1``.
|
||||
|
||||
CPU pinning policy
|
||||
For the libvirt driver, you can pin the virtual CPUs (vCPUs) of instances to
|
||||
the host's physical CPU cores (pCPUs) using properties. You can further
|
||||
refine this by stating how hardware CPU threads in a simultaneous
|
||||
multithreading-based (SMT) architecture be used. These configurations will
|
||||
result in improved per-instance determinism and performance.
|
||||
|
||||
.. note::
|
||||
|
||||
SMT-based architectures include Intel processors with Hyper-Threading
|
||||
technology. In these architectures, processor cores share a number of
|
||||
components with one or more other cores. Cores in such architectures are
|
||||
commonly referred to as hardware threads, while the cores that a given
|
||||
core share components with are known as thread siblings.
|
||||
|
||||
.. note::
|
||||
|
||||
Host aggregates should be used to separate these pinned instances from
|
||||
unpinned instances as the latter will not respect the resourcing
|
||||
requirements of the former.
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property hw:cpu_policy=CPU-POLICY \
|
||||
--property hw:cpu_thread_policy=CPU-THREAD-POLICY
|
||||
|
||||
Valid CPU-POLICY values are:
|
||||
|
||||
- ``shared``: (default) The guest vCPUs will be allowed to freely float
|
||||
across host pCPUs, albeit potentially constrained by NUMA policy.
|
||||
- ``dedicated``: The guest vCPUs will be strictly pinned to a set of host
|
||||
pCPUs. In the absence of an explicit vCPU topology request, the drivers
|
||||
typically expose all vCPUs as sockets with one core and one thread. When
|
||||
strict CPU pinning is in effect the guest CPU topology will be setup to
|
||||
match the topology of the CPUs to which it is pinned. This option implies
|
||||
an overcommit ratio of 1.0. For example, if a two vCPU guest is pinned to a
|
||||
single host core with two threads, then the guest will get a topology of
|
||||
one socket, one core, two threads.
|
||||
|
||||
Valid CPU-THREAD-POLICY values are:
|
||||
|
||||
- ``prefer``: (default) The host may or may not have an SMT architecture.
|
||||
Where an SMT architecture is present, thread siblings are preferred.
|
||||
- ``isolate``: The host must not have an SMT architecture or must emulate a
|
||||
non-SMT architecture. If the host does not have an SMT architecture, each
|
||||
vCPU is placed on a different core as expected. If the host does have an
|
||||
SMT architecture - that is, one or more cores have thread siblings - then
|
||||
each vCPU is placed on a different physical core. No vCPUs from other
|
||||
guests are placed on the same core. All but one thread sibling on each
|
||||
utilized core is therefore guaranteed to be unusable.
|
||||
- ``require``: The host must have an SMT architecture. Each vCPU is allocated
|
||||
on thread siblings. If the host does not have an SMT architecture, then it
|
||||
is not used. If the host has an SMT architecture, but not enough cores with
|
||||
free thread siblings are available, then scheduling fails.
|
||||
|
||||
.. note::
|
||||
|
||||
The ``hw:cpu_thread_policy`` option is only valid if ``hw:cpu_policy`` is
|
||||
set to ``dedicated``.
|
||||
|
||||
NUMA topology
|
||||
For the libvirt driver, you can define the host NUMA placement for the
|
||||
instance vCPU threads as well as the allocation of instance vCPUs and memory
|
||||
from the host NUMA nodes. For flavors whose memory and vCPU allocations are
|
||||
larger than the size of NUMA nodes in the compute hosts, the definition of a
|
||||
NUMA topology allows hosts to better utilize NUMA and improve performance of
|
||||
the instance OS.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property hw:numa_nodes=FLAVOR-NODES \
|
||||
--property hw:numa_cpus.N=FLAVOR-CORES \
|
||||
--property hw:numa_mem.N=FLAVOR-MEMORY
|
||||
|
||||
Where:
|
||||
|
||||
- FLAVOR-NODES: (integer) The number of host NUMA nodes to restrict execution
|
||||
of instance vCPU threads to. If not specified, the vCPU threads can run on
|
||||
any number of the host NUMA nodes available.
|
||||
- N: (integer) The instance NUMA node to apply a given CPU or memory
|
||||
configuration to, where N is in the range ``0`` to ``FLAVOR-NODES - 1``.
|
||||
- FLAVOR-CORES: (comma-separated list of integers) A list of instance vCPUs
|
||||
to map to instance NUMA node N. If not specified, vCPUs are evenly divided
|
||||
among available NUMA nodes.
|
||||
- FLAVOR-MEMORY: (integer) The number of MB of instance memory to map to
|
||||
instance NUMA node N. If not specified, memory is evenly divided among
|
||||
available NUMA nodes.
|
||||
|
||||
.. note::
|
||||
|
||||
``hw:numa_cpus.N`` and ``hw:numa_mem.N`` are only valid if
|
||||
``hw:numa_nodes`` is set. Additionally, they are only required if the
|
||||
instance's NUMA nodes have an asymmetrical allocation of CPUs and RAM
|
||||
(important for some NFV workloads).
|
||||
|
||||
.. note::
|
||||
|
||||
The ``N`` parameter is an index of *guest* NUMA nodes and may not
|
||||
correspond to *host* NUMA nodes. For example, on a platform with two NUMA
|
||||
nodes, the scheduler may opt to place guest NUMA node 0, as referenced in
|
||||
``hw:numa_mem.0`` on host NUMA node 1 and vice versa. Similarly, the
|
||||
integers used for ``FLAVOR-CORES`` are indexes of *guest* vCPUs and may
|
||||
not correspond to *host* CPUs. As such, this feature cannot be used to
|
||||
constrain instances to specific host CPUs or NUMA nodes.
|
||||
|
||||
.. warning::
|
||||
|
||||
If the combined values of ``hw:numa_cpus.N`` or ``hw:numa_mem.N`` are
|
||||
greater than the available number of CPUs or memory respectively, an
|
||||
exception is raised.
|
||||
|
||||
Large pages allocation
|
||||
You can configure the size of large pages used to back the VMs.
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property hw:mem_page_size=PAGE_SIZE
|
||||
|
||||
Valid ``PAGE_SIZE`` values are:
|
||||
|
||||
- ``small``: (default) The smallest page size is used. Example: 4 KB on x86.
|
||||
- ``large``: Only use larger page sizes for guest RAM. Example: either 2 MB
|
||||
or 1 GB on x86.
|
||||
- ``any``: It is left up to the compute driver to decide. In this case, the
|
||||
libvirt driver might try to find large pages, but fall back to small pages.
|
||||
Other drivers may choose alternate policies for ``any``.
|
||||
- pagesize: (string) An explicit page size can be set if the workload has
|
||||
specific requirements. This value can be an integer value for the page size
|
||||
in KB, or can use any standard suffix. Example: ``4KB``, ``2MB``,
|
||||
``2048``, ``1GB``.
|
||||
|
||||
.. note::
|
||||
|
||||
Large pages can be enabled for guest RAM without any regard to whether the
|
||||
guest OS will use them or not. If the guest OS chooses not to use huge
|
||||
pages, it will merely see small pages as before. Conversely, if a guest OS
|
||||
does intend to use huge pages, it is very important that the guest RAM be
|
||||
backed by huge pages. Otherwise, the guest OS will not be getting the
|
||||
performance benefit it is expecting.
|
||||
|
||||
PCI passthrough
|
||||
You can assign PCI devices to a guest by specifying them in the flavor.
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property pci_passthrough:alias=ALIAS:COUNT
|
||||
|
||||
Where:
|
||||
|
||||
- ALIAS: (string) The alias which correspond to a particular PCI device class
|
||||
as configured in the nova configuration file (see `nova.conf configuration
|
||||
options
|
||||
<https://docs.openstack.org/ocata/config-reference/compute/config-options.html>`_).
|
||||
- COUNT: (integer) The amount of PCI devices of type ALIAS to be assigned to
|
||||
a guest.
|
||||
|
||||
Secure Boot
|
||||
When your Compute services use the Hyper-V hypervisor, you can enable secure
|
||||
boot for Windows and Linux instances.
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ openstack flavor set FLAVOR-NAME \
|
||||
--property os:secure_boot=SECURE_BOOT_OPTION
|
||||
|
||||
Valid ``SECURE_BOOT_OPTION`` values are:
|
||||
|
||||
- ``required``: Enable Secure Boot for instances running with this flavor.
|
||||
- ``disabled`` or ``optional``: (default) Disable Secure Boot for instances
|
||||
running with this flavor.
|
||||
|
|
@ -0,0 +1,239 @@
|
|||
==========
|
||||
Huge pages
|
||||
==========
|
||||
|
||||
The huge page feature in OpenStack provides important performance improvements
|
||||
for applications that are highly memory IO-bound.
|
||||
|
||||
.. note::
|
||||
|
||||
Huge pages may also be referred to hugepages or large pages, depending on
|
||||
the source. These terms are synonyms.
|
||||
|
||||
Pages, the TLB and huge pages
|
||||
-----------------------------
|
||||
|
||||
Pages
|
||||
Physical memory is segmented into a series of contiguous regions called
|
||||
pages. Each page contains a number of bytes, referred to as the page size.
|
||||
The system retrieves memory by accessing entire pages, rather than byte by
|
||||
byte.
|
||||
|
||||
Translation Lookaside Buffer (TLB)
|
||||
A TLB is used to map the virtual addresses of pages to the physical addresses
|
||||
in actual memory. The TLB is a cache and is not limitless, storing only the
|
||||
most recent or frequently accessed pages. During normal operation, processes
|
||||
will sometimes attempt to retrieve pages that are not stored in the cache.
|
||||
This is known as a TLB miss and results in a delay as the processor iterates
|
||||
through the pages themselves to find the missing address mapping.
|
||||
|
||||
Huge Pages
|
||||
The standard page size in x86 systems is 4 kB. This is optimal for general
|
||||
purpose computing but larger page sizes - 2 MB and 1 GB - are also available.
|
||||
These larger page sizes are known as huge pages. Huge pages result in less
|
||||
efficient memory usage as a process will not generally use all memory
|
||||
available in each page. However, use of huge pages will result in fewer
|
||||
overall pages and a reduced risk of TLB misses. For processes that have
|
||||
significant memory requirements or are memory intensive, the benefits of huge
|
||||
pages frequently outweigh the drawbacks.
|
||||
|
||||
Persistent Huge Pages
|
||||
On Linux hosts, persistent huge pages are huge pages that are reserved
|
||||
upfront. The HugeTLB provides for the mechanism for this upfront
|
||||
configuration of huge pages. The HugeTLB allows for the allocation of varying
|
||||
quantities of different huge page sizes. Allocation can be made at boot time
|
||||
or run time. Refer to the `Linux hugetlbfs guide`_ for more information.
|
||||
|
||||
Transparent Huge Pages (THP)
|
||||
On Linux hosts, transparent huge pages are huge pages that are automatically
|
||||
provisioned based on process requests. Transparent huge pages are provisioned
|
||||
on a best effort basis, attempting to provision 2 MB huge pages if available
|
||||
but falling back to 4 kB small pages if not. However, no upfront
|
||||
configuration is necessary. Refer to the `Linux THP guide`_ for more
|
||||
information.
|
||||
|
||||
Enabling huge pages on the host
|
||||
-------------------------------
|
||||
|
||||
Persistent huge pages are required owing to their guaranteed availability.
|
||||
However, persistent huge pages are not enabled by default in most environments.
|
||||
The steps for enabling huge pages differ from platform to platform and only the
|
||||
steps for Linux hosts are described here. On Linux hosts, the number of
|
||||
persistent huge pages on the host can be queried by checking ``/proc/meminfo``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ grep Huge /proc/meminfo
|
||||
AnonHugePages: 0 kB
|
||||
ShmemHugePages: 0 kB
|
||||
HugePages_Total: 0
|
||||
HugePages_Free: 0
|
||||
HugePages_Rsvd: 0
|
||||
HugePages_Surp: 0
|
||||
Hugepagesize: 2048 kB
|
||||
|
||||
In this instance, there are 0 persistent huge pages (``HugePages_Total``) and 0
|
||||
transparent huge pages (``AnonHugePages``) allocated. Huge pages can be
|
||||
allocated at boot time or run time. Huge pages require a contiguous area of
|
||||
memory - memory that gets increasingly fragmented the long a host is running.
|
||||
Identifying contiguous areas of memory is a issue for all huge page sizes, but
|
||||
it is particularly problematic for larger huge page sizes such as 1 GB huge
|
||||
pages. Allocating huge pages at boot time will ensure the correct number of huge
|
||||
pages is always available, while allocating them at run time can fail if memory
|
||||
has become too fragmented.
|
||||
|
||||
To allocate huge pages at run time, the kernel boot parameters must be extended
|
||||
to include some huge page-specific parameters. This can be achieved by
|
||||
modifying ``/etc/default/grub`` and appending the ``hugepagesz``,
|
||||
``hugepages``, and ``transparent_hugepages=never`` arguments to
|
||||
``GRUB_CMDLINE_LINUX``. To allocate, for example, 2048 persistent 2 MB huge
|
||||
pages at boot time, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# echo 'GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX hugepagesz=2M hugepages=2048 transparent_hugepage=never"' > /etc/default/grub
|
||||
$ grep GRUB_CMDLINE_LINUX /etc/default/grub
|
||||
GRUB_CMDLINE_LINUX="..."
|
||||
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX hugepagesz=2M hugepages=2048 transparent_hugepage=never"
|
||||
|
||||
.. important::
|
||||
|
||||
Persistent huge pages are not usable by standard host OS processes. Ensure
|
||||
enough free, non-huge page memory is reserved for these processes.
|
||||
|
||||
Reboot the host, then validate that huge pages are now available:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ grep "Huge" /proc/meminfo
|
||||
AnonHugePages: 0 kB
|
||||
ShmemHugePages: 0 kB
|
||||
HugePages_Total: 2048
|
||||
HugePages_Free: 2048
|
||||
HugePages_Rsvd: 0
|
||||
HugePages_Surp: 0
|
||||
Hugepagesize: 2048 kB
|
||||
|
||||
There are now 2048 2 MB huge pages totalling 4 GB of huge pages. These huge
|
||||
pages must be mounted. On most platforms, this happens automatically. To verify
|
||||
that the huge pages are mounted, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# mount | grep huge
|
||||
hugetlbfs on /dev/hugepages type hugetlbfs (rw)
|
||||
|
||||
In this instance, the huge pages are mounted at ``/dev/hugepages``. This mount
|
||||
point varies from platform to platform. If the above command did not return
|
||||
anything, the hugepages must be mounted manually. To mount the huge pages at
|
||||
``/dev/hugepages``, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# mkdir -p /dev/hugepages
|
||||
# mount -t hugetlbfs hugetlbfs /dev/hugepages
|
||||
|
||||
There are many more ways to configure huge pages, including allocating huge
|
||||
pages at run time, specifying varying allocations for different huge page
|
||||
sizes, or allocating huge pages from memory affinitized to different NUMA
|
||||
nodes. For more information on configuring huge pages on Linux hosts, refer to
|
||||
the `Linux hugetlbfs guide`_.
|
||||
|
||||
Customizing instance huge pages allocations
|
||||
-------------------------------------------
|
||||
|
||||
.. important::
|
||||
|
||||
The functionality described below is currently only supported by the
|
||||
libvirt/KVM driver.
|
||||
|
||||
.. important::
|
||||
|
||||
For performance reasons, configuring huge pages for an instance will
|
||||
implicitly result in a NUMA topology being configured for the instance.
|
||||
Configuring a NUMA topology for an instance requires enablement of
|
||||
``NUMATopologyFilter``. Refer to :doc:`cpu-topologies` for more
|
||||
information.
|
||||
|
||||
By default, an instance does not use huge pages for its underlying memory.
|
||||
However, huge pages can bring important or required performance improvements
|
||||
for some workloads. Huge pages must be requested explicitly through the use of
|
||||
flavor extra specs or image metadata. To request an instance use huge pages,
|
||||
run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:mem_page_size=large
|
||||
|
||||
Different platforms offer different huge page sizes. For example: x86-based
|
||||
platforms offer 2 MB and 1 GB huge page sizes. Specific huge page sizes can be
|
||||
also be requested, with or without a unit suffix. The unit suffix must be one
|
||||
of: Kb(it), Kib(it), Mb(it), Mib(it), Gb(it), Gib(it), Tb(it), Tib(it), KB,
|
||||
KiB, MB, MiB, GB, GiB, TB, TiB. Where a unit suffix is not provided, Kilobytes
|
||||
are assumed. To request an instance to use 2 MB huge pages, run one of:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:mem_page_size=2Mb
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:mem_page_size=2048
|
||||
|
||||
Enabling huge pages for an instance can have negative consequences for other
|
||||
instances by consuming limited huge pages resources. To explicitly request
|
||||
an instance use small pages, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:mem_page_size=small
|
||||
|
||||
.. note::
|
||||
|
||||
Explicitly requesting any page size will still result in a NUMA topology
|
||||
being applied to the instance, as described earlier in this document.
|
||||
|
||||
Finally, to leave the decision of huge or small pages to the compute driver,
|
||||
run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:mem_page_size=any
|
||||
|
||||
For more information about the syntax for ``hw:mem_page_size``, refer to the
|
||||
`Flavors`_ guide.
|
||||
|
||||
Applications are frequently packaged as images. For applications that require
|
||||
the IO performance improvements that huge pages provides, configure image
|
||||
metadata to ensure instances always request the specific page size regardless
|
||||
of flavor. To configure an image to use 1 GB huge pages, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack image set [IMAGE_ID] --property hw_mem_page_size=1GB
|
||||
|
||||
If the flavor specifies a numerical page size or a page size of "small" the
|
||||
image is not allowed to specify a page size and if it does an exception will
|
||||
be raised. If the flavor specifies a page size of ``any`` or ``large`` then
|
||||
any page size specified in the image will be used. By setting a ``small``
|
||||
page size in the flavor, administrators can prevent users requesting huge
|
||||
pages in flavors and impacting resource utilization. To configure this page
|
||||
size, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set m1.large --property hw:mem_page_size=small
|
||||
|
||||
.. note::
|
||||
|
||||
Explicitly requesting any page size will still result in a NUMA topology
|
||||
being applied to the instance, as described earlier in this document.
|
||||
|
||||
For more information about image metadata, refer to the `Image metadata`_
|
||||
guide.
|
||||
|
||||
.. Links
|
||||
.. _`Linux THP guide`: https://www.kernel.org/doc/Documentation/vm/transhuge.txt
|
||||
.. _`Linux hugetlbfs guide`: https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
|
||||
.. _`Flavors`: https://docs.openstack.org/admin-guide/compute-flavors.html
|
||||
.. _`Image metadata`: https://docs.openstack.org/image-guide/image-metadata.html
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
=======
|
||||
Compute
|
||||
=======
|
||||
|
||||
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.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
arch.rst
|
||||
networking-nova.rst
|
||||
system-admin.rst
|
||||
support-compute.rst
|
||||
|
|
@ -0,0 +1,314 @@
|
|||
======================
|
||||
Live-migrate instances
|
||||
======================
|
||||
|
||||
Live-migrating an instance means moving its virtual machine to a different
|
||||
OpenStack Compute server while the instance continues running. Before starting
|
||||
a live-migration, review the chapter
|
||||
:ref:`section_configuring-compute-migrations`. It covers the configuration
|
||||
settings required to enable live-migration, but also reasons for migrations and
|
||||
non-live-migration options.
|
||||
|
||||
The instructions below cover shared-storage and volume-backed migration. To
|
||||
block-migrate instances, add the command-line option
|
||||
:command:``--block-migrate`` to the :command:``nova live-migration`` command,
|
||||
and :command:``--block-migration`` to the :command:``openstack server migrate``
|
||||
command.
|
||||
|
||||
.. _section-manual-selection-of-dest:
|
||||
|
||||
Manual selection of the destination host
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Obtain the ID of the instance you want to migrate:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server list
|
||||
|
||||
+--------------------------------------+------+--------+-----------------+------------+
|
||||
| ID | Name | Status | Networks | Image Name |
|
||||
+--------------------------------------+------+--------+-----------------+------------+
|
||||
| d1df1b5a-70c4-4fed-98b7-423362f2c47c | vm1 | ACTIVE | private=a.b.c.d | ... |
|
||||
| d693db9e-a7cf-45ef-a7c9-b3ecb5f22645 | vm2 | ACTIVE | private=e.f.g.h | ... |
|
||||
+--------------------------------------+------+--------+-----------------+------------+
|
||||
|
||||
#. Determine on which host the instance is currently running. In this example,
|
||||
``vm1`` is running on ``HostB``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server show d1df1b5a-70c4-4fed-98b7-423362f2c47c
|
||||
|
||||
+----------------------+--------------------------------------+
|
||||
| Field | Value |
|
||||
+----------------------+--------------------------------------+
|
||||
| ... | ... |
|
||||
| OS-EXT-SRV-ATTR:host | HostB |
|
||||
| ... | ... |
|
||||
| addresses | a.b.c.d |
|
||||
| flavor | m1.tiny |
|
||||
| id | d1df1b5a-70c4-4fed-98b7-423362f2c47c |
|
||||
| name | vm1 |
|
||||
| status | ACTIVE |
|
||||
| ... | ... |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
#. Select the compute node the instance will be migrated to. In this example,
|
||||
we will migrate the instance to ``HostC``, because ``nova-compute`` is
|
||||
running on it:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack compute service list
|
||||
|
||||
+----+------------------+-------+----------+---------+-------+----------------------------+
|
||||
| ID | Binary | Host | Zone | Status | State | Updated At |
|
||||
+----+------------------+-------+----------+---------+-------+----------------------------+
|
||||
| 3 | nova-conductor | HostA | internal | enabled | up | 2017-02-18T09:42:29.000000 |
|
||||
| 4 | nova-scheduler | HostA | internal | enabled | up | 2017-02-18T09:42:26.000000 |
|
||||
| 5 | nova-consoleauth | HostA | internal | enabled | up | 2017-02-18T09:42:29.000000 |
|
||||
| 6 | nova-compute | HostB | nova | enabled | up | 2017-02-18T09:42:29.000000 |
|
||||
| 7 | nova-compute | HostC | nova | enabled | up | 2017-02-18T09:42:29.000000 |
|
||||
+----+------------------+-------+----------+---------+-------+----------------------------+
|
||||
|
||||
#. Check that ``HostC`` has enough resources for migration:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack host show HostC
|
||||
|
||||
+-------+------------+-----+-----------+---------+
|
||||
| Host | Project | CPU | Memory MB | Disk GB |
|
||||
+-------+------------+-----+-----------+---------+
|
||||
| HostC | (total) | 16 | 32232 | 878 |
|
||||
| HostC | (used_now) | 22 | 21284 | 422 |
|
||||
| HostC | (used_max) | 22 | 21284 | 422 |
|
||||
| HostC | p1 | 22 | 21284 | 422 |
|
||||
| HostC | p2 | 22 | 21284 | 422 |
|
||||
+-------+------------+-----+-----------+---------+
|
||||
|
||||
- ``cpu``: Number of CPUs
|
||||
|
||||
- ``memory_mb``: Total amount of memory, in MB
|
||||
|
||||
- ``disk_gb``: Total amount of space for NOVA-INST-DIR/instances, in GB
|
||||
|
||||
In this table, the first row shows the total amount of resources available
|
||||
on the physical server. The second line shows the currently used resources.
|
||||
The third line shows the maximum used resources. The fourth line and below
|
||||
shows the resources available for each project.
|
||||
|
||||
#. Migrate the instance:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server migrate d1df1b5a-70c4-4fed-98b7-423362f2c47c --live HostC
|
||||
|
||||
#. Confirm that the instance has been migrated successfully:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server show d1df1b5a-70c4-4fed-98b7-423362f2c47c
|
||||
|
||||
+----------------------+--------------------------------------+
|
||||
| Field | Value |
|
||||
+----------------------+--------------------------------------+
|
||||
| ... | ... |
|
||||
| OS-EXT-SRV-ATTR:host | HostC |
|
||||
| ... | ... |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
If the instance is still running on ``HostB``, the migration failed. The
|
||||
``nova-scheduler`` and ``nova-conductor`` log files on the controller and
|
||||
the ``nova-compute`` log file on the source compute host can help pin-point
|
||||
the problem.
|
||||
|
||||
.. _auto_selection_of_dest:
|
||||
|
||||
Automatic selection of the destination host
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To leave the selection of the destination host to the Compute service, use the
|
||||
nova command-line client.
|
||||
|
||||
#. Obtain the instance ID as shown in step 1 of the section
|
||||
:ref:`section-manual-selection-of-dest`.
|
||||
|
||||
#. Leave out the host selection steps 2, 3, and 4.
|
||||
|
||||
#. Migrate the instance:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova live-migration d1df1b5a-70c4-4fed-98b7-423362f2c47c
|
||||
|
||||
Monitoring the migration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Confirm that the instance is migrating:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server show d1df1b5a-70c4-4fed-98b7-423362f2c47c
|
||||
|
||||
+----------------------+--------------------------------------+
|
||||
| Field | Value |
|
||||
+----------------------+--------------------------------------+
|
||||
| ... | ... |
|
||||
| status | MIGRATING |
|
||||
| ... | ... |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
#. Check progress
|
||||
|
||||
Use the nova command-line client for nova's migration monitoring feature.
|
||||
First, obtain the migration ID:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova server-migration-list d1df1b5a-70c4-4fed-98b7-423362f2c47c
|
||||
+----+-------------+----------- (...)
|
||||
| Id | Source Node | Dest Node | (...)
|
||||
+----+-------------+-----------+ (...)
|
||||
| 2 | - | - | (...)
|
||||
+----+-------------+-----------+ (...)
|
||||
|
||||
For readability, most output columns were removed. Only the first column,
|
||||
**Id**, is relevant. In this example, the migration ID is 2. Use this to
|
||||
get the migration status.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova server-migration-show d1df1b5a-70c4-4fed-98b7-423362f2c47c 2
|
||||
+------------------------+--------------------------------------+
|
||||
| Property | Value |
|
||||
+------------------------+--------------------------------------+
|
||||
| created_at | 2017-03-08T02:53:06.000000 |
|
||||
| dest_compute | controller |
|
||||
| dest_host | - |
|
||||
| dest_node | - |
|
||||
| disk_processed_bytes | 0 |
|
||||
| disk_remaining_bytes | 0 |
|
||||
| disk_total_bytes | 0 |
|
||||
| id | 2 |
|
||||
| memory_processed_bytes | 65502513 |
|
||||
| memory_remaining_bytes | 786427904 |
|
||||
| memory_total_bytes | 1091379200 |
|
||||
| server_uuid | d1df1b5a-70c4-4fed-98b7-423362f2c47c |
|
||||
| source_compute | compute2 |
|
||||
| source_node | - |
|
||||
| status | running |
|
||||
| updated_at | 2017-03-08T02:53:47.000000 |
|
||||
+------------------------+--------------------------------------+
|
||||
|
||||
The output shows that the migration is running. Progress is measured by the
|
||||
number of memory bytes that remain to be copied. If this number is not
|
||||
decreasing over time, the migration may be unable to complete, and it may be
|
||||
aborted by the Compute service.
|
||||
|
||||
.. note::
|
||||
|
||||
The command reports that no disk bytes are processed, even in the event
|
||||
of block migration.
|
||||
|
||||
What to do when the migration times out
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
During the migration process, the instance may write to a memory page after
|
||||
that page has been copied to the destination. When that happens, the same page
|
||||
has to be copied again. The instance may write to memory pages faster than they
|
||||
can be copied, so that the migration cannot complete. The Compute service will
|
||||
cancel it when the ``live_migration_completion_timeout``, a configuration
|
||||
parameter, is reached.
|
||||
|
||||
The following remarks assume the KVM/Libvirt hypervisor.
|
||||
|
||||
How to know that the migration timed out
|
||||
----------------------------------------
|
||||
|
||||
To determine that the migration timed out, inspect the ``nova-compute`` log
|
||||
file on the source host. The following log entry shows that the migration timed
|
||||
out:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# grep WARNING.*d1df1b5a-70c4-4fed-98b7-423362f2c47c /var/log/nova/nova-compute.log
|
||||
...
|
||||
WARNING nova.virt.libvirt.migration [req-...] [instance: ...]
|
||||
live migration not completed after 1800 sec
|
||||
|
||||
The Compute service also cancels migrations when the memory copy seems to make
|
||||
no progress. Ocata disables this feature by default, but it can be enabled
|
||||
using the configuration parameter ``live_migration_progress_timeout``. Should
|
||||
this be the case, you may find the following message in the log:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
WARNING nova.virt.libvirt.migration [req-...] [instance: ...]
|
||||
live migration stuck for 150 sec
|
||||
|
||||
Addressing migration timeouts
|
||||
-----------------------------
|
||||
|
||||
To stop the migration from putting load on infrastructure resources like
|
||||
network and disks, you may opt to cancel it manually.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova live-migration-abort INSTANCE_ID MIGRATION_ID
|
||||
|
||||
To make live-migration succeed, you have several options:
|
||||
|
||||
- **Manually force-complete the migration**
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova live-migration-force-complete INSTANCE_ID MIGRATION_ID
|
||||
|
||||
The instance is paused until memory copy completes.
|
||||
|
||||
.. caution::
|
||||
|
||||
Since the pause impacts time keeping on the instance and not all
|
||||
applications tolerate incorrect time settings, use this approach with
|
||||
caution.
|
||||
|
||||
- **Enable auto-convergence**
|
||||
|
||||
Auto-convergence is a Libvirt feature. Libvirt detects that the migration is
|
||||
unlikely to complete and slows down its CPU until the memory copy process is
|
||||
faster than the instance's memory writes.
|
||||
|
||||
To enable auto-convergence, set
|
||||
``live_migration_permit_auto_convergence=true`` in ``nova.conf`` and restart
|
||||
``nova-compute``. Do this on all compute hosts.
|
||||
|
||||
.. caution::
|
||||
|
||||
One possible downside of auto-convergence is the slowing down of the
|
||||
instance.
|
||||
|
||||
- **Enable post-copy**
|
||||
|
||||
This is a Libvirt feature. Libvirt detects that the migration does not
|
||||
progress and responds by activating the virtual machine on the destination
|
||||
host before all its memory has been copied. Access to missing memory pages
|
||||
result in page faults that are satisfied from the source host.
|
||||
|
||||
To enable post-copy, set ``live_migration_permit_post_copy=true`` in
|
||||
``nova.conf`` and restart ``nova-compute``. Do this on all compute hosts.
|
||||
|
||||
When post-copy is enabled, manual force-completion does not pause the
|
||||
instance but switches to the post-copy process.
|
||||
|
||||
.. caution::
|
||||
|
||||
Possible downsides:
|
||||
|
||||
- When the network connection between source and destination is
|
||||
interrupted, page faults cannot be resolved anymore, and the virtual
|
||||
machine is rebooted.
|
||||
|
||||
- Post-copy may lead to an increased page fault rate during migration,
|
||||
which can slow the instance down.
|
||||
|
|
@ -0,0 +1,230 @@
|
|||
=======
|
||||
Logging
|
||||
=======
|
||||
|
||||
Logging module
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Logging behavior can be changed by creating a configuration file. To specify
|
||||
the configuration file, add this line to the ``/etc/nova/nova.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
log-config=/etc/nova/logging.conf
|
||||
|
||||
To change the logging level, add ``DEBUG``, ``INFO``, ``WARNING``, or ``ERROR``
|
||||
as a parameter.
|
||||
|
||||
The logging configuration file is an INI-style configuration file, which must
|
||||
contain a section called ``logger_nova``. This controls the behavior of the
|
||||
logging facility in the ``nova-*`` services. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[logger_nova]
|
||||
level = INFO
|
||||
handlers = stderr
|
||||
qualname = nova
|
||||
|
||||
This example sets the debugging level to ``INFO`` (which is less verbose than
|
||||
the default ``DEBUG`` setting).
|
||||
|
||||
For more about the logging configuration syntax, including the ``handlers`` and
|
||||
``quaname`` variables, see the `Python documentation
|
||||
<https://docs.python.org/release/2.7/library/logging.html#configuration-file-format>`__
|
||||
on logging configuration files.
|
||||
|
||||
For an example of the ``logging.conf`` file with various defined handlers, see
|
||||
the `OpenStack Configuration Reference
|
||||
<https://docs.openstack.org/ocata/config-reference/>`__.
|
||||
|
||||
Syslog
|
||||
~~~~~~
|
||||
|
||||
OpenStack Compute services can send logging information to syslog. This is
|
||||
useful if you want to use rsyslog to forward logs to a remote machine.
|
||||
Separately configure the Compute service (nova), the Identity service
|
||||
(keystone), the Image service (glance), and, if you are using it, the Block
|
||||
Storage service (cinder) to send log messages to syslog. Open these
|
||||
configuration files:
|
||||
|
||||
- ``/etc/nova/nova.conf``
|
||||
|
||||
- ``/etc/keystone/keystone.conf``
|
||||
|
||||
- ``/etc/glance/glance-api.conf``
|
||||
|
||||
- ``/etc/glance/glance-registry.conf``
|
||||
|
||||
- ``/etc/cinder/cinder.conf``
|
||||
|
||||
In each configuration file, add these lines:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
debug = False
|
||||
use_syslog = True
|
||||
syslog_log_facility = LOG_LOCAL0
|
||||
|
||||
In addition to enabling syslog, these settings also turn off debugging output
|
||||
from the log.
|
||||
|
||||
.. note::
|
||||
|
||||
Although this example uses the same local facility for each service
|
||||
(``LOG_LOCAL0``, which corresponds to syslog facility ``LOCAL0``), we
|
||||
recommend that you configure a separate local facility for each service, as
|
||||
this provides better isolation and more flexibility. For example, you can
|
||||
capture logging information at different severity levels for different
|
||||
services. syslog allows you to define up to eight local facilities,
|
||||
``LOCAL0, LOCAL1, ..., LOCAL7``. For more information, see the syslog
|
||||
documentation.
|
||||
|
||||
Rsyslog
|
||||
~~~~~~~
|
||||
|
||||
rsyslog is useful for setting up a centralized log server across multiple
|
||||
machines. This section briefly describe the configuration to set up an rsyslog
|
||||
server. A full treatment of rsyslog is beyond the scope of this book. This
|
||||
section assumes rsyslog has already been installed on your hosts (it is
|
||||
installed by default on most Linux distributions).
|
||||
|
||||
This example provides a minimal configuration for ``/etc/rsyslog.conf`` on the
|
||||
log server host, which receives the log files
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# provides TCP syslog reception
|
||||
$ModLoad imtcp
|
||||
$InputTCPServerRun 1024
|
||||
|
||||
Add a filter rule to ``/etc/rsyslog.conf`` which looks for a host name. This
|
||||
example uses COMPUTE_01 as the compute host name:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
:hostname, isequal, "COMPUTE_01" /mnt/rsyslog/logs/compute-01.log
|
||||
|
||||
On each compute host, create a file named ``/etc/rsyslog.d/60-nova.conf``, with
|
||||
the following content:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
# prevent debug from dnsmasq with the daemon.none parameter
|
||||
*.*;auth,authpriv.none,daemon.none,local0.none -/var/log/syslog
|
||||
# Specify a log level of ERROR
|
||||
local0.error @@172.20.1.43:1024
|
||||
|
||||
Once you have created the file, restart the ``rsyslog`` service. Error-level
|
||||
log messages on the compute hosts should now be sent to the log server.
|
||||
|
||||
Serial console
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The serial console provides a way to examine kernel output and other system
|
||||
messages during troubleshooting if the instance lacks network connectivity.
|
||||
|
||||
Read-only access from server serial console is possible using the
|
||||
``os-GetSerialOutput`` server action. Most cloud images enable this feature by
|
||||
default. For more information, see :ref:`compute-common-errors-and-fixes`.
|
||||
|
||||
OpenStack Juno and later supports read-write access using the serial console
|
||||
using the ``os-GetSerialConsole`` server action. This feature also requires a
|
||||
websocket client to access the serial console.
|
||||
|
||||
.. rubric:: Configuring read-write serial console access
|
||||
|
||||
#. On a compute node, edit the ``/etc/nova/nova.conf`` file:
|
||||
|
||||
In the ``[serial_console]`` section, enable the serial console:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[serial_console]
|
||||
# ...
|
||||
enabled = true
|
||||
|
||||
#. In the ``[serial_console]`` section, configure the serial console proxy
|
||||
similar to graphical console proxies:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[serial_console]
|
||||
# ...
|
||||
base_url = ws://controller:6083/
|
||||
listen = 0.0.0.0
|
||||
proxyclient_address = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
|
||||
The ``base_url`` option specifies the base URL that clients receive from the
|
||||
API upon requesting a serial console. Typically, this refers to the host
|
||||
name of the controller node.
|
||||
|
||||
The ``listen`` option specifies the network interface nova-compute should
|
||||
listen on for virtual console connections. Typically, 0.0.0.0 will enable
|
||||
listening on all interfaces.
|
||||
|
||||
The ``proxyclient_address`` option specifies which network interface the
|
||||
proxy should connect to. Typically, this refers to the IP address of the
|
||||
management interface.
|
||||
|
||||
When you enable read-write serial console access, Compute will add serial
|
||||
console information to the Libvirt XML file for the instance. For example:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<console type='tcp'>
|
||||
<source mode='bind' host='127.0.0.1' service='10000'/>
|
||||
<protocol type='raw'/>
|
||||
<target type='serial' port='0'/>
|
||||
<alias name='serial0'/>
|
||||
</console>
|
||||
|
||||
.. rubric:: Accessing the serial console on an instance
|
||||
|
||||
#. Use the :command:`nova get-serial-proxy` command to retrieve the websocket
|
||||
URL for the serial console on the instance:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova get-serial-proxy INSTANCE_NAME
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 0
|
||||
:widths: 9 65
|
||||
|
||||
* - Type
|
||||
- Url
|
||||
* - serial
|
||||
- ws://127.0.0.1:6083/?token=18510769-71ad-4e5a-8348-4218b5613b3d
|
||||
|
||||
Alternatively, use the API directly:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ curl -i 'http://<controller>:8774/v2.1/<tenant_uuid>/servers/<instance_uuid>/action' \
|
||||
-X POST \
|
||||
-H "Accept: application/json" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "X-Auth-Project-Id: <project_id>" \
|
||||
-H "X-Auth-Token: <auth_token>" \
|
||||
-d '{"os-getSerialConsole": {"type": "serial"}}'
|
||||
|
||||
#. Use Python websocket with the URL to generate ``.send``, ``.recv``, and
|
||||
``.fileno`` methods for serial console access. For example:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import websocket
|
||||
ws = websocket.create_connection(
|
||||
'ws://127.0.0.1:6083/?token=18510769-71ad-4e5a-8348-4218b5613b3d',
|
||||
subprotocols=['binary', 'base64'])
|
||||
|
||||
Alternatively, use a `Python websocket client
|
||||
<https://github.com/larsks/novaconsole/>`__.
|
||||
|
||||
.. note::
|
||||
|
||||
When you enable the serial console, typical instance logging using the
|
||||
:command:`nova console-log` command is disabled. Kernel output and other
|
||||
system messages will not be visible unless you are actively viewing the
|
||||
serial console.
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
.. _section_manage-the-cloud:
|
||||
|
||||
================
|
||||
Manage the cloud
|
||||
================
|
||||
|
||||
.. toctree::
|
||||
|
||||
euca2ools.rst
|
||||
common/nova-show-usage-statistics-for-hosts-instances.rst
|
||||
|
||||
System administrators can use the :command:`openstack` and :command:`euca2ools`
|
||||
commands to manage their clouds.
|
||||
|
||||
The ``openstack`` client and ``euca2ools`` can be used by all users, though
|
||||
specific commands might be restricted by the Identity service.
|
||||
|
||||
**Managing the cloud with the openstack client**
|
||||
|
||||
#. The ``python-openstackclient`` package provides an ``openstack`` shell that
|
||||
enables Compute API interactions from the command line. Install the client,
|
||||
and provide your user name and password (which can be set as environment
|
||||
variables for convenience), for the ability to administer the cloud from the
|
||||
command line.
|
||||
|
||||
To install python-openstackclient, follow the instructions in the `OpenStack
|
||||
User Guide
|
||||
<https://docs.openstack.org/user-guide/common/cli-install-openstack-command-line-clients.html>`_.
|
||||
|
||||
#. Confirm the installation was successful:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack help
|
||||
usage: openstack [--version] [-v | -q] [--log-file LOG_FILE] [-h] [--debug]
|
||||
[--os-cloud <cloud-config-name>]
|
||||
[--os-region-name <auth-region-name>]
|
||||
[--os-cacert <ca-bundle-file>] [--verify | --insecure]
|
||||
[--os-default-domain <auth-domain>]
|
||||
...
|
||||
|
||||
Running :command:`openstack help` returns a list of ``openstack`` commands
|
||||
and parameters. To get help for a subcommand, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack help SUBCOMMAND
|
||||
|
||||
For a complete list of ``openstack`` commands and parameters, see the
|
||||
`OpenStack Command-Line Reference
|
||||
<https://docs.openstack.org/cli-reference/openstack.html>`__.
|
||||
|
||||
#. Set the required parameters as environment variables to make running
|
||||
commands easier. For example, you can add ``--os-username`` as an
|
||||
``openstack`` option, or set it as an environment variable. To set the user
|
||||
name, password, and project as environment variables, use:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ export OS_USERNAME=joecool
|
||||
$ export OS_PASSWORD=coolword
|
||||
$ export OS_TENANT_NAME=coolu
|
||||
|
||||
#. The Identity service gives you an authentication endpoint, which Compute
|
||||
recognizes as ``OS_AUTH_URL``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ export OS_AUTH_URL=http://hostname:5000/v2.0
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
.. _section_manage-compute-users:
|
||||
|
||||
====================
|
||||
Manage Compute users
|
||||
====================
|
||||
|
||||
Access to the Euca2ools (ec2) API is controlled by an access key and a secret
|
||||
key. The user's access key needs to be included in the request, and the request
|
||||
must be signed with the secret key. Upon receipt of API requests, Compute
|
||||
verifies the signature and runs commands on behalf of the user.
|
||||
|
||||
To begin using Compute, you must create a user with the Identity service.
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
==============
|
||||
Manage volumes
|
||||
==============
|
||||
|
||||
Depending on the setup of your cloud provider, they may give you an endpoint to
|
||||
use to manage volumes, or there may be an extension under the covers. In either
|
||||
case, you can use the ``openstack`` CLI to manage volumes.
|
||||
|
||||
.. list-table:: **openstack volume commands**
|
||||
:header-rows: 1
|
||||
|
||||
* - Command
|
||||
- Description
|
||||
* - server add volume
|
||||
- Attach a volume to a server.
|
||||
* - volume create
|
||||
- Add a new volume.
|
||||
* - volume delete
|
||||
- Remove or delete a volume.
|
||||
* - server remove volume
|
||||
- Detach or remove a volume from a server.
|
||||
* - volume list
|
||||
- List all the volumes.
|
||||
* - volume show
|
||||
- Show details about a volume.
|
||||
* - snapshot create
|
||||
- Add a new snapshot.
|
||||
* - snapshot delete
|
||||
- Remove a snapshot.
|
||||
* - snapshot list
|
||||
- List all the snapshots.
|
||||
* - snapshot show
|
||||
- Show details about a snapshot.
|
||||
* - volume type create
|
||||
- Create a new volume type.
|
||||
* - volume type delete
|
||||
- Delete a specific flavor
|
||||
* - volume type list
|
||||
- Print a list of available 'volume types'.
|
||||
|
||||
|
|
||||
|
||||
For example, to list IDs and names of volumes, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack volume list
|
||||
+--------+--------------+-----------+------+-------------+
|
||||
| ID | Display Name | Status | Size | Attached to |
|
||||
+--------+--------------+-----------+------+-------------+
|
||||
| 86e6cb | testnfs | available | 1 | |
|
||||
| e389f7 | demo | available | 1 | |
|
||||
+--------+--------------+-----------+------+-------------+
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,335 @@
|
|||
==================================
|
||||
Recover from a failed compute node
|
||||
==================================
|
||||
|
||||
If you deploy Compute with a shared file system, you can use several methods to
|
||||
quickly recover from a node failure. This section discusses manual recovery.
|
||||
|
||||
Evacuate instances
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If a hardware malfunction or other error causes the cloud compute node to fail,
|
||||
you can use the :command:`nova evacuate` command to evacuate instances. See
|
||||
the `OpenStack Administrator Guide
|
||||
<https://docs.openstack.org/admin-guide/cli-nova-evacuate.html>`__.
|
||||
|
||||
.. _nova-compute-node-down-manual-recovery:
|
||||
|
||||
Manual recovery
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
To manually recover a failed compute node:
|
||||
|
||||
#. Identify the VMs on the affected hosts by using a combination of the
|
||||
:command:`openstack server list` and :command:`openstack server show`
|
||||
commands or the :command:`euca-describe-instances` command.
|
||||
|
||||
For example, this command displays information about the i-000015b9 instance
|
||||
that runs on the np-rcc54 node:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ euca-describe-instances
|
||||
i-000015b9 at3-ui02 running nectarkey (376, np-rcc54) 0 m1.xxlarge 2012-06-19T00:48:11.000Z 115.146.93.60
|
||||
|
||||
#. Query the Compute database for the status of the host. This example converts
|
||||
an EC2 API instance ID to an OpenStack ID. If you use the :command:`nova`
|
||||
commands, you can substitute the ID directly. This example output is
|
||||
truncated:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
mysql> SELECT * FROM instances WHERE id = CONV('15b9', 16, 10) \G;
|
||||
*************************** 1. row ***************************
|
||||
created_at: 2012-06-19 00:48:11
|
||||
updated_at: 2012-07-03 00:35:11
|
||||
deleted_at: NULL
|
||||
...
|
||||
id: 5561
|
||||
...
|
||||
power_state: 5
|
||||
vm_state: shutoff
|
||||
...
|
||||
hostname: at3-ui02
|
||||
host: np-rcc54
|
||||
...
|
||||
uuid: 3f57699a-e773-4650-a443-b4b37eed5a06
|
||||
...
|
||||
task_state: NULL
|
||||
...
|
||||
|
||||
.. note::
|
||||
|
||||
Find the credentials for your database in ``/etc/nova.conf`` file.
|
||||
|
||||
#. Decide to which compute host to move the affected VM. Run this database
|
||||
command to move the VM to that host:
|
||||
|
||||
.. code-block:: mysql
|
||||
|
||||
mysql> UPDATE instances SET host = 'np-rcc46' WHERE uuid = '3f57699a-e773-4650-a443-b4b37eed5a06';
|
||||
|
||||
#. If you use a hypervisor that relies on libvirt, such as KVM, update the
|
||||
``libvirt.xml`` file in ``/var/lib/nova/instances/[instance ID]`` with these
|
||||
changes:
|
||||
|
||||
- Change the ``DHCPSERVER`` value to the host IP address of the new compute
|
||||
host.
|
||||
|
||||
- Update the VNC IP to ``0.0.0.0``.
|
||||
|
||||
#. Reboot the VM:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server reboot 3f57699a-e773-4650-a443-b4b37eed5a06
|
||||
|
||||
Typically, the database update and :command:`openstack server reboot` command
|
||||
recover a VM from a failed host. However, if problems persist, try one of these
|
||||
actions:
|
||||
|
||||
- Use :command:`virsh` to recreate the network filter configuration.
|
||||
|
||||
- Restart Compute services.
|
||||
|
||||
- Update the ``vm_state`` and ``power_state`` fields in the Compute database.
|
||||
|
||||
Recover from a UID/GID mismatch
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Sometimes when you run Compute with a shared file system or an automated
|
||||
configuration tool, files on your compute node might use the wrong UID or GID.
|
||||
This UID or GID mismatch can prevent you from running live migrations or
|
||||
starting virtual machines.
|
||||
|
||||
This procedure runs on ``nova-compute`` hosts, based on the KVM hypervisor:
|
||||
|
||||
#. Set the nova UID to the same number in ``/etc/passwd`` on all hosts. For
|
||||
example, set the UID to ``112``.
|
||||
|
||||
.. note::
|
||||
|
||||
Choose UIDs or GIDs that are not in use for other users or groups.
|
||||
|
||||
#. Set the ``libvirt-qemu`` UID to the same number in the ``/etc/passwd`` file
|
||||
on all hosts. For example, set the UID to ``119``.
|
||||
|
||||
#. Set the ``nova`` group to the same number in the ``/etc/group`` file on all
|
||||
hosts. For example, set the group to ``120``.
|
||||
|
||||
#. Set the ``libvirtd`` group to the same number in the ``/etc/group`` file on
|
||||
all hosts. For example, set the group to ``119``.
|
||||
|
||||
#. Stop the services on the compute node.
|
||||
|
||||
#. Change all files that the nova user or group owns. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# find / -uid 108 -exec chown nova {} \;
|
||||
# note the 108 here is the old nova UID before the change
|
||||
# find / -gid 120 -exec chgrp nova {} \;
|
||||
|
||||
#. Repeat all steps for the ``libvirt-qemu`` files, if required.
|
||||
|
||||
#. Restart the services.
|
||||
|
||||
#. To verify that all files use the correct IDs, run the :command:`find`
|
||||
command.
|
||||
|
||||
Recover cloud after disaster
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This section describes how to manage your cloud after a disaster and back up
|
||||
persistent storage volumes. Backups are mandatory, even outside of disaster
|
||||
scenarios.
|
||||
|
||||
For a definition of a disaster recovery plan (DRP), see
|
||||
`https://en.wikipedia.org/wiki/Disaster\_Recovery\_Plan
|
||||
<https://en.wikipedia.org/wiki/Disaster_Recovery_Plan>`_.
|
||||
|
||||
A disk crash, network loss, or power failure can affect several components in
|
||||
your cloud architecture. The worst disaster for a cloud is a power loss. A
|
||||
power loss affects these components:
|
||||
|
||||
- A cloud controller (``nova-api``, ``nova-objectstore``, ``nova-network``)
|
||||
|
||||
- A compute node (``nova-compute``)
|
||||
|
||||
- A storage area network (SAN) used by OpenStack Block Storage
|
||||
(``cinder-volumes``)
|
||||
|
||||
Before a power loss:
|
||||
|
||||
- Create an active iSCSI session from the SAN to the cloud controller (used
|
||||
for the ``cinder-volumes`` LVM's VG).
|
||||
|
||||
- Create an active iSCSI session from the cloud controller to the compute node
|
||||
(managed by ``cinder-volume``).
|
||||
|
||||
- Create an iSCSI session for every volume (so 14 EBS volumes requires 14
|
||||
iSCSI sessions).
|
||||
|
||||
- Create ``iptables`` or ``ebtables`` rules from the cloud controller to the
|
||||
compute node. This allows access from the cloud controller to the running
|
||||
instance.
|
||||
|
||||
- Save the current state of the database, the current state of the running
|
||||
instances, and the attached volumes (mount point, volume ID, volume status,
|
||||
etc), at least from the cloud controller to the compute node.
|
||||
|
||||
After power resumes and all hardware components restart:
|
||||
|
||||
- The iSCSI session from the SAN to the cloud no longer exists.
|
||||
|
||||
- The iSCSI session from the cloud controller to the compute node no longer
|
||||
exists.
|
||||
|
||||
- nova-network reapplies configurations on boot and, as a result, recreates
|
||||
the iptables and ebtables from the cloud controller to the compute node.
|
||||
|
||||
- Instances stop running.
|
||||
|
||||
Instances are not lost because neither ``destroy`` nor ``terminate`` ran.
|
||||
The files for the instances remain on the compute node.
|
||||
|
||||
- The database does not update.
|
||||
|
||||
.. rubric:: Begin recovery
|
||||
|
||||
.. warning::
|
||||
|
||||
Do not add any steps or change the order of steps in this procedure.
|
||||
|
||||
#. Check the current relationship between the volume and its instance, so that
|
||||
you can recreate the attachment.
|
||||
|
||||
Use the :command:`openstack volume list` command to get this information.
|
||||
Note that the :command:`openstack` client can get volume information from
|
||||
OpenStack Block Storage.
|
||||
|
||||
#. Update the database to clean the stalled state. Do this for every volume by
|
||||
using these queries:
|
||||
|
||||
.. code-block:: mysql
|
||||
|
||||
mysql> use cinder;
|
||||
mysql> update volumes set mountpoint=NULL;
|
||||
mysql> update volumes set status="available" where status <>"error_deleting";
|
||||
mysql> update volumes set attach_status="detached";
|
||||
mysql> update volumes set instance_id=0;
|
||||
|
||||
Use :command:`openstack volume list` command to list all volumes.
|
||||
|
||||
#. Restart the instances by using the :command:`openstack server reboot
|
||||
INSTANCE` command.
|
||||
|
||||
.. important::
|
||||
|
||||
Some instances completely reboot and become reachable, while some might
|
||||
stop at the plymouth stage. This is expected behavior. DO NOT reboot a
|
||||
second time.
|
||||
|
||||
Instance state at this stage depends on whether you added an `/etc/fstab`
|
||||
entry for that volume. Images built with the cloud-init package remain in
|
||||
a ``pending`` state, while others skip the missing volume and start. You
|
||||
perform this step to ask Compute to reboot every instance so that the
|
||||
stored state is preserved. It does not matter if not all instances come
|
||||
up successfully. For more information about cloud-init, see
|
||||
`help.ubuntu.com/community/CloudInit/
|
||||
<https://help.ubuntu.com/community/CloudInit/>`__.
|
||||
|
||||
#. If required, run the :command:`openstack server add volume` command to
|
||||
reattach the volumes to their respective instances. This example uses a file
|
||||
of listed volumes to reattach them:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
while read line; do
|
||||
volume=`echo $line | $CUT -f 1 -d " "`
|
||||
instance=`echo $line | $CUT -f 2 -d " "`
|
||||
mount_point=`echo $line | $CUT -f 3 -d " "`
|
||||
echo "ATTACHING VOLUME FOR INSTANCE - $instance"
|
||||
openstack server add volume $instance $volume $mount_point
|
||||
sleep 2
|
||||
done < $volumes_tmp_file
|
||||
|
||||
Instances that were stopped at the plymouth stage now automatically continue
|
||||
booting and start normally. Instances that previously started successfully
|
||||
can now see the volume.
|
||||
|
||||
#. Log in to the instances with SSH and reboot them.
|
||||
|
||||
If some services depend on the volume or if a volume has an entry in fstab,
|
||||
you can now restart the instance. Restart directly from the instance itself
|
||||
and not through :command:`nova`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# shutdown -r now
|
||||
|
||||
When you plan for and complete a disaster recovery, follow these tips:
|
||||
|
||||
- Use the ``errors=remount`` option in the ``fstab`` file to prevent data
|
||||
corruption.
|
||||
|
||||
In the event of an I/O error, this option prevents writes to the disk. Add
|
||||
this configuration option into the cinder-volume server that performs the
|
||||
iSCSI connection to the SAN and into the instances' ``fstab`` files.
|
||||
|
||||
- Do not add the entry for the SAN's disks to the cinder-volume's ``fstab``
|
||||
file.
|
||||
|
||||
Some systems hang on that step, which means you could lose access to your
|
||||
cloud-controller. To re-run the session manually, run this command before
|
||||
performing the mount:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# iscsiadm -m discovery -t st -p $SAN_IP $ iscsiadm -m node --target-name $IQN -p $SAN_IP -l
|
||||
|
||||
- On your instances, if you have the whole ``/home/`` directory on the disk,
|
||||
leave a user's directory with the user's bash files and the
|
||||
``authorized_keys`` file instead of emptying the ``/home/`` directory and
|
||||
mapping the disk on it.
|
||||
|
||||
This action enables you to connect to the instance without the volume
|
||||
attached, if you allow only connections through public keys.
|
||||
|
||||
To script the disaster recovery plan (DRP), use the `https://github.com/Razique
|
||||
<https://github.com/Razique/BashStuff/blob/master/SYSTEMS/OpenStack/SCR_5006_V00_NUAC-OPENSTACK-DRP-OpenStack.sh>`_
|
||||
bash script.
|
||||
|
||||
This script completes these steps:
|
||||
|
||||
#. Creates an array for instances and their attached volumes.
|
||||
|
||||
#. Updates the MySQL database.
|
||||
|
||||
#. Restarts all instances with euca2ools.
|
||||
|
||||
#. Reattaches the volumes.
|
||||
|
||||
#. Uses Compute credentials to make an SSH connection into every instance.
|
||||
|
||||
The script includes a ``test mode``, which enables you to perform the sequence
|
||||
for only one instance.
|
||||
|
||||
To reproduce the power loss, connect to the compute node that runs that
|
||||
instance and close the iSCSI session. Do not detach the volume by using the
|
||||
:command:`openstack server remove volume` command. You must manually close the
|
||||
iSCSI session. This example closes an iSCSI session with the number ``15``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# iscsiadm -m session -u -r 15
|
||||
|
||||
Do not forget the ``-r`` option. Otherwise, all sessions close.
|
||||
|
||||
.. warning::
|
||||
|
||||
There is potential for data loss while running instances during this
|
||||
procedure. If you are using Liberty or earlier, ensure you have the correct
|
||||
patch and set the options appropriately.
|
||||
|
|
@ -0,0 +1,148 @@
|
|||
========================================
|
||||
Attaching physical PCI devices to guests
|
||||
========================================
|
||||
|
||||
The PCI passthrough feature in OpenStack allows full access and direct control
|
||||
of a physical PCI device in guests. This mechanism is generic for any kind of
|
||||
PCI device, and runs with a Network Interface Card (NIC), Graphics Processing
|
||||
Unit (GPU), or any other devices that can be attached to a PCI bus. Correct
|
||||
driver installation is the only requirement for the guest to properly use the
|
||||
devices.
|
||||
|
||||
Some PCI devices provide Single Root I/O Virtualization and Sharing (SR-IOV)
|
||||
capabilities. When SR-IOV is used, a physical device is virtualized and appears
|
||||
as multiple PCI devices. Virtual PCI devices are assigned to the same or
|
||||
different guests. In the case of PCI passthrough, the full physical device is
|
||||
assigned to only one guest and cannot be shared.
|
||||
|
||||
.. note::
|
||||
|
||||
For information on attaching virtual SR-IOV devices to guests, refer to the
|
||||
`Networking Guide`_.
|
||||
|
||||
To enable PCI passthrough, follow the steps below:
|
||||
|
||||
#. Configure nova-scheduler (Controller)
|
||||
|
||||
#. Configure nova-api (Controller)**
|
||||
|
||||
#. Configure a flavor (Controller)
|
||||
|
||||
#. Enable PCI passthrough (Compute)
|
||||
|
||||
#. Configure PCI devices in nova-compute (Compute)
|
||||
|
||||
.. note::
|
||||
|
||||
The PCI device with address ``0000:41:00.0`` is used as an example. This
|
||||
will differ between environments.
|
||||
|
||||
Configure nova-scheduler (Controller)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Configure ``nova-scheduler`` as specified in `Configure nova-scheduler`_.
|
||||
|
||||
#. Restart the ``nova-scheduler`` service.
|
||||
|
||||
Configure nova-api (Controller)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Specify the PCI alias for the device.
|
||||
|
||||
Configure a PCI alias ``a1`` to request a PCI device with a ``vendor_id`` of
|
||||
``0x8086`` and a ``product_id`` of ``0x154d``. The ``vendor_id`` and
|
||||
``product_id`` correspond the PCI device with address ``0000:41:00.0``.
|
||||
|
||||
Edit ``/etc/nova/nova.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[default]
|
||||
pci_alias = { "vendor_id":"8086", "product_id":"154d", "device_type":"type-PF", "name":"a1" }
|
||||
|
||||
For more information about the syntax of ``pci_alias``, refer to `nova.conf
|
||||
configuration options`_.
|
||||
|
||||
#. Restart the ``nova-api`` service.
|
||||
|
||||
Configure a flavor (Controller)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Configure a flavor to request two PCI devices, each with ``vendor_id`` of
|
||||
``0x8086`` and ``product_id`` of ``0x154d``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# openstack flavor set m1.large --property "pci_passthrough:alias"="a1:2"
|
||||
|
||||
For more information about the syntax for ``pci_passthrough:alias``, refer to
|
||||
`flavor`_.
|
||||
|
||||
Enable PCI passthrough (Compute)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Enable VT-d and IOMMU. For more information, refer to steps one and two in
|
||||
`Create Virtual Functions`_.
|
||||
|
||||
Configure PCI devices (Compute)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Configure ``nova-compute`` to allow the PCI device to pass through to
|
||||
VMs. Edit ``/etc/nova/nova.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[default]
|
||||
pci_passthrough_whitelist = { "address": "0000:41:00.0" }
|
||||
|
||||
Alternatively specify multiple PCI devices using whitelisting:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[default]
|
||||
pci_passthrough_whitelist = { "vendor_id": "8086", "product_id": "10fb" }
|
||||
|
||||
All PCI devices matching the ``vendor_id`` and ``product_id`` are added to
|
||||
the pool of PCI devices available for passthrough to VMs.
|
||||
|
||||
For more information about the syntax of ``pci_passthrough_whitelist``,
|
||||
refer to `nova.conf configuration options`_.
|
||||
|
||||
#. Specify the PCI alias for the device.
|
||||
|
||||
From the Newton release, to resize guest with PCI device, configure the PCI
|
||||
alias on the compute node as well.
|
||||
|
||||
Configure a PCI alias ``a1`` to request a PCI device with a ``vendor_id`` of
|
||||
``0x8086`` and a ``product_id`` of ``0x154d``. The ``vendor_id`` and
|
||||
``product_id`` correspond the PCI device with address ``0000:41:00.0``.
|
||||
|
||||
Edit ``/etc/nova/nova.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[default]
|
||||
pci_alias = { "vendor_id":"8086", "product_id":"154d", "device_type":"type-PF", "name":"a1" }
|
||||
|
||||
For more information about the syntax of ``pci_alias``, refer to `nova.conf
|
||||
configuration options`_.
|
||||
|
||||
#. Restart the ``nova-compute`` service.
|
||||
|
||||
Create instances with PCI passthrough devices
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``nova-scheduler`` selects a destination host that has PCI devices
|
||||
available with the specified ``vendor_id`` and ``product_id`` that matches the
|
||||
``pci_alias`` from the flavor.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# openstack server create --flavor m1.large --image cirros-0.3.5-x86_64-uec --wait test-pci
|
||||
|
||||
.. Links
|
||||
.. _`Create Virtual Functions`: https://docs.openstack.org/ocata/networking-guide/config-sriov.html#create-virtual-functions-compute
|
||||
.. _`Configure nova-scheduler`: https://docs.openstack.org/ocata/networking-guide/config-sriov.html#configure-nova-scheduler-controller
|
||||
.. _`nova.conf configuration options`: https://docs.openstack.org/ocata/config-reference/compute/config-options.html
|
||||
.. _`flavor`: https://docs.openstack.org/admin-guide/compute-flavors.html
|
||||
.. _`Networking Guide`: https://docs.openstack.org/ocata/networking-guide/config-sriov.html
|
||||
|
|
@ -0,0 +1,322 @@
|
|||
===============================
|
||||
Configure remote console access
|
||||
===============================
|
||||
|
||||
To provide a remote console or remote desktop access to guest virtual machines,
|
||||
use VNC or SPICE HTML5 through either the OpenStack dashboard or the command
|
||||
line. Best practice is to select one or the other to run.
|
||||
|
||||
About nova-consoleauth
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Both 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.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
#. A user connects to the API and gets an ``access_url`` such as,
|
||||
``http://ip:port/?token=xyz``.
|
||||
|
||||
#. The user pastes the URL in a browser or uses it as a client
|
||||
parameter.
|
||||
|
||||
#. 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 compute host specifies the address that the proxy should use to connect
|
||||
through the ``nova.conf`` file option, ``vncserver_proxyclient_address``. 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:
|
||||
|
||||
- Bridges between the public network where the clients live and the private
|
||||
network where VNC servers live.
|
||||
|
||||
- Mediates token authentication.
|
||||
|
||||
- Transparently deals with hypervisor-specific connection details to provide a
|
||||
uniform client experience.
|
||||
|
||||
.. figure:: figures/SCH_5009_V00_NUAC-VNC_OpenStack.png
|
||||
:alt: noVNC process
|
||||
:width: 95%
|
||||
|
||||
VNC configuration options
|
||||
-------------------------
|
||||
|
||||
To customize the VNC console, use the following configuration options in your
|
||||
``nova.conf`` file:
|
||||
|
||||
.. note::
|
||||
|
||||
To support :ref:`live migration <section_configuring-compute-migrations>`,
|
||||
you cannot specify a specific IP address for ``vncserver_listen``, because
|
||||
that IP address does not exist on the destination host.
|
||||
|
||||
.. list-table:: **Description of VNC configuration options**
|
||||
:header-rows: 1
|
||||
:widths: 25 25
|
||||
|
||||
* - 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"
|
||||
* - vncserver_listen = 127.0.0.1
|
||||
- (StrOpt) IP address on which instance vncservers should listen
|
||||
* - vncserver_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"
|
||||
|
||||
.. note::
|
||||
|
||||
- The ``vncserver_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:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# apt-get install nova-novncproxy
|
||||
|
||||
The service starts automatically on installation.
|
||||
|
||||
To restart the service, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# service nova-novncproxy restart
|
||||
|
||||
The configuration option parameter should point to your ``nova.conf`` file,
|
||||
which includes the message queue server address and credentials.
|
||||
|
||||
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:
|
||||
|
||||
- ``vncserver_listen=0.0.0.0``
|
||||
|
||||
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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
<graphics type="vnc" autoport="yes" keymap="en-us" listen="0.0.0.0"/>
|
||||
|
||||
.. note::
|
||||
|
||||
To use live migration, use the 0.0.0.0 address.
|
||||
|
||||
- ``vncserver_proxyclient_address=127.0.0.1``
|
||||
|
||||
The address of the compute host that Compute instructs proxies to use when
|
||||
connecting to instance ``vncservers``.
|
||||
|
||||
Frequently asked questions about VNC access to virtual machines
|
||||
---------------------------------------------------------------
|
||||
|
||||
- **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
|
||||
support through a web browser.
|
||||
|
||||
- **Q: I want VNC support in the OpenStack dashboard. What services do I
|
||||
need?**
|
||||
|
||||
A: You need ``nova-novncproxy``, ``nova-consoleauth``, and correctly
|
||||
configured compute hosts.
|
||||
|
||||
- **Q: When I use ``nova get-vnc-console`` or click on the VNC tab of the
|
||||
OpenStack dashboard, it hangs. Why?**
|
||||
|
||||
A: Make sure you are running ``nova-consoleauth`` (in addition to
|
||||
``nova-novncproxy``). The proxies rely on ``nova-consoleauth`` to validate
|
||||
tokens, and waits for a reply from them until a timeout is reached.
|
||||
|
||||
- **Q: My VNC proxy worked fine during my all-in-one test, but now it doesn't
|
||||
work on multi host. Why?**
|
||||
|
||||
A: The default options work for an all-in-one install, but changes must be
|
||||
made on your compute hosts once you start to build a cluster. As an example,
|
||||
suppose you have two servers:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
PROXYSERVER (public_ip=172.24.1.1, management_ip=192.168.1.1)
|
||||
COMPUTESERVER (management_ip=192.168.1.2)
|
||||
|
||||
Your ``nova-compute`` configuration file must set the following values:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# These flags help construct a connection data structure
|
||||
vncserver_proxyclient_address=192.168.1.2
|
||||
novncproxy_base_url=http://172.24.1.1:6080/vnc_auto.html
|
||||
xvpvncproxy_base_url=http://172.24.1.1:6081/console
|
||||
|
||||
# This is the address where the underlying vncserver (not the proxy)
|
||||
# will listen for connections.
|
||||
vncserver_listen=192.168.1.2
|
||||
|
||||
.. note::
|
||||
|
||||
``novncproxy_base_url`` and ``xvpvncproxy_base_url`` use a public IP; this
|
||||
is the URL that is ultimately returned to clients, which generally do not
|
||||
have access to your private network. Your PROXYSERVER must be able to
|
||||
reach ``vncserver_proxyclient_address``, because that is the address over
|
||||
which the VNC connection is proxied.
|
||||
|
||||
- **Q: My noVNC does not work with recent versions of web browsers. Why?**
|
||||
|
||||
A: Make sure you have installed ``python-numpy``, which is required to
|
||||
support a newer version of the WebSocket protocol (HyBi-07+).
|
||||
|
||||
- **Q: How do I adjust the dimensions of the VNC window image in the OpenStack
|
||||
dashboard?**
|
||||
|
||||
A: These values are hard-coded in a Django HTML template. To alter them, edit
|
||||
the ``_detail_vnc.html`` template file. The location of this file varies
|
||||
based on Linux distribution. On Ubuntu 14.04, the file is at
|
||||
``/usr/share/pyshared/horizon/dashboards/nova/instances/templates/instances/_detail_vnc.html``.
|
||||
|
||||
Modify the ``width`` and ``height`` options, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
<iframe src="{{ vnc_url }}" width="720" height="430"></iframe>
|
||||
|
||||
- **Q: My noVNC connections failed with ValidationError: Origin header protocol
|
||||
does not match. Why?**
|
||||
|
||||
A: Make sure the ``base_url`` match your TLS setting. If you are using https
|
||||
console connections, make sure that the value of ``novncproxy_base_url`` is
|
||||
set explicitly where the ``nova-novncproxy`` service is running.
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
====================
|
||||
Secure with rootwrap
|
||||
====================
|
||||
|
||||
Rootwrap allows unprivileged users to safely run Compute actions as the root
|
||||
user. Compute previously used :command:`sudo` for this purpose, but this was
|
||||
difficult to maintain, and did not allow advanced filters. The
|
||||
:command:`rootwrap` command replaces :command:`sudo` for Compute.
|
||||
|
||||
To use rootwrap, prefix the Compute command with :command:`nova-rootwrap`. For
|
||||
example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo nova-rootwrap /etc/nova/rootwrap.conf command
|
||||
|
||||
A generic ``sudoers`` entry lets the Compute user run :command:`nova-rootwrap`
|
||||
as root. The :command:`nova-rootwrap` code looks for filter definition
|
||||
directories in its configuration file, and loads command filters from them. It
|
||||
then checks if the command requested by Compute matches one of those filters
|
||||
and, if so, executes the command (as root). If no filter matches, it denies the
|
||||
request.
|
||||
|
||||
.. note::
|
||||
|
||||
Be aware of issues with using NFS and root-owned files. The NFS share must
|
||||
be configured with the ``no_root_squash`` option enabled, in order for
|
||||
rootwrap to work correctly.
|
||||
|
||||
Rootwrap is fully controlled by the root user. The root user owns the sudoers
|
||||
entry which allows Compute to run a specific rootwrap executable as root, and
|
||||
only with a specific configuration file (which should also be owned by root).
|
||||
The :command:`nova-rootwrap` command imports the Python modules it needs from a
|
||||
cleaned, system-default PYTHONPATH. The root-owned configuration file points
|
||||
to root-owned filter definition directories, which contain root-owned filters
|
||||
definition files. This chain ensures that the Compute user itself is not in
|
||||
control of the configuration or modules used by the :command:`nova-rootwrap`
|
||||
executable.
|
||||
|
||||
Configure rootwrap
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Configure rootwrap in the ``rootwrap.conf`` file. Because it is in the trusted
|
||||
security path, it must be owned and writable by only the root user. The
|
||||
``rootwrap_config=entry`` parameter specifies the file's location in the
|
||||
sudoers entry and in the ``nova.conf`` configuration file.
|
||||
|
||||
The ``rootwrap.conf`` file uses an INI file format with these sections and
|
||||
parameters:
|
||||
|
||||
.. list-table:: **rootwrap.conf configuration options**
|
||||
:widths: 64 31
|
||||
|
||||
* - Configuration option=Default value
|
||||
- (Type) Description
|
||||
* - [DEFAULT]
|
||||
filters\_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap
|
||||
- (ListOpt) Comma-separated list of directories
|
||||
containing filter definition files.
|
||||
Defines where rootwrap filters are stored.
|
||||
Directories defined on this line should all
|
||||
exist, and be owned and writable only by the
|
||||
root user.
|
||||
|
||||
If the root wrapper is not performing correctly, you can add a workaround
|
||||
option into the ``nova.conf`` configuration file. This workaround re-configures
|
||||
the root wrapper configuration to fall back to running commands as ``sudo``,
|
||||
and is a Kilo release feature.
|
||||
|
||||
Including this workaround in your configuration file safeguards your
|
||||
environment from issues that can impair root wrapper performance. Tool changes
|
||||
that have impacted `Python Build Reasonableness (PBR)
|
||||
<https://git.openstack.org/cgit/openstack-dev/pbr/>`__ for example, are a known
|
||||
issue that affects root wrapper performance.
|
||||
|
||||
To set up this workaround, configure the ``disable_rootwrap`` option in the
|
||||
``[workaround]`` section of the ``nova.conf`` configuration file.
|
||||
|
||||
The filters definition files contain lists of filters that rootwrap will use to
|
||||
allow or deny a specific command. They are generally suffixed by ``.filters`` .
|
||||
Since they are in the trusted security path, they need to be owned and writable
|
||||
only by the root user. Their location is specified in the ``rootwrap.conf``
|
||||
file.
|
||||
|
||||
Filter definition files use an INI file format with a ``[Filters]`` section and
|
||||
several lines, each with a unique parameter name, which should be different for
|
||||
each filter you define:
|
||||
|
||||
.. list-table:: **Filters configuration options**
|
||||
:widths: 72 39
|
||||
|
||||
|
||||
* - Configuration option=Default value
|
||||
- (Type) Description
|
||||
* - [Filters]
|
||||
filter\_name=kpartx: CommandFilter, /sbin/kpartx, root
|
||||
- (ListOpt) Comma-separated list containing the filter class to
|
||||
use, followed by the Filter arguments (which vary depending
|
||||
on the Filter class selected).
|
||||
|
||||
Configure the rootwrap daemon
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Administrators can use rootwrap daemon support instead of running rootwrap with
|
||||
:command:`sudo`. The rootwrap daemon reduces the overhead and performance loss
|
||||
that results from running ``oslo.rootwrap`` with :command:`sudo`. Each call
|
||||
that needs rootwrap privileges requires a new instance of rootwrap. The daemon
|
||||
prevents overhead from the repeated calls. The daemon does not support long
|
||||
running processes, however.
|
||||
|
||||
To enable the rootwrap daemon, set ``use_rootwrap_daemon`` to ``True`` in the
|
||||
Compute service configuration file.
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
==================
|
||||
Security hardening
|
||||
==================
|
||||
|
||||
OpenStack Compute can be integrated with various third-party technologies to
|
||||
increase security. For more information, see the `OpenStack Security Guide
|
||||
<https://docs.openstack.org/security-guide/>`_.
|
||||
|
||||
Trusted compute pools
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Administrators can designate a group of compute hosts as trusted using trusted
|
||||
compute pools. The trusted hosts use hardware-based security features, such as
|
||||
the Intel Trusted Execution Technology (TXT), to provide an additional level of
|
||||
security. Combined with an external stand-alone, web-based remote attestation
|
||||
server, cloud providers can ensure that the compute node runs only software
|
||||
with verified measurements and can ensure a secure cloud stack.
|
||||
|
||||
Trusted compute pools provide the ability for cloud subscribers to request
|
||||
services run only on verified compute nodes.
|
||||
|
||||
The remote attestation server performs node verification like this:
|
||||
|
||||
1. Compute nodes boot with Intel TXT technology enabled.
|
||||
|
||||
2. The compute node BIOS, hypervisor, and operating system are measured.
|
||||
|
||||
3. When the attestation server challenges the compute node, the measured data
|
||||
is sent to the attestation server.
|
||||
|
||||
4. The attestation server verifies the measurements against a known good
|
||||
database to determine node trustworthiness.
|
||||
|
||||
A description of how to set up an attestation service is beyond the scope of
|
||||
this document. For an open source project that you can use to implement an
|
||||
attestation service, see the `Open Attestation
|
||||
<https://github.com/OpenAttestation/OpenAttestation>`__ project.
|
||||
|
||||
.. figure:: figures/OpenStackTrustedComputePool1.png
|
||||
|
||||
**Configuring Compute to use trusted compute pools**
|
||||
|
||||
#. Enable scheduling support for trusted compute pools by adding these lines to
|
||||
the ``DEFAULT`` section of the ``/etc/nova/nova.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
|
||||
scheduler_available_filters=nova.scheduler.filters.all_filters
|
||||
scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter,TrustedFilter
|
||||
|
||||
#. Specify the connection information for your attestation service by adding
|
||||
these lines to the ``trusted_computing`` section of the
|
||||
``/etc/nova/nova.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[trusted_computing]
|
||||
attestation_server = 10.1.71.206
|
||||
attestation_port = 8443
|
||||
# If using OAT v2.0 after, use this port:
|
||||
# attestation_port = 8181
|
||||
attestation_server_ca_file = /etc/nova/ssl.10.1.71.206.crt
|
||||
# If using OAT v1.5, use this api_url:
|
||||
attestation_api_url = /AttestationService/resources
|
||||
# If using OAT pre-v1.5, use this api_url:
|
||||
# attestation_api_url = /OpenAttestationWebServices/V1.0
|
||||
attestation_auth_blob = i-am-openstack
|
||||
|
||||
In this example:
|
||||
|
||||
``server``
|
||||
Host name or IP address of the host that runs the attestation service
|
||||
|
||||
``port``
|
||||
HTTPS port for the attestation service
|
||||
|
||||
``server_ca_file``
|
||||
Certificate file used to verify the attestation server's identity
|
||||
|
||||
``api_url``
|
||||
The attestation service's URL path
|
||||
|
||||
``auth_blob``
|
||||
An authentication blob, required by the attestation service.
|
||||
|
||||
#. Save the file, and restart the ``nova-compute`` and ``nova-scheduler``
|
||||
service to pick up the changes.
|
||||
|
||||
To customize the trusted compute pools, use these configuration option
|
||||
settings:
|
||||
|
||||
.. list-table:: **Description of trusted computing configuration options**
|
||||
:header-rows: 2
|
||||
|
||||
* - Configuration option = Default value
|
||||
- Description
|
||||
* - [trusted_computing]
|
||||
-
|
||||
* - attestation_api_url = /OpenAttestationWebServices/V1.0
|
||||
- (StrOpt) Attestation web API URL
|
||||
* - attestation_auth_blob = None
|
||||
- (StrOpt) Attestation authorization blob - must change
|
||||
* - attestation_auth_timeout = 60
|
||||
- (IntOpt) Attestation status cache valid period length
|
||||
* - attestation_insecure_ssl = False
|
||||
- (BoolOpt) Disable SSL cert verification for Attestation service
|
||||
* - attestation_port = 8443
|
||||
- (StrOpt) Attestation server port
|
||||
* - attestation_server = None
|
||||
- (StrOpt) Attestation server HTTP
|
||||
* - attestation_server_ca_file = None
|
||||
- (StrOpt) Attestation server Cert file for Identity verification
|
||||
|
||||
**Specifying trusted flavors**
|
||||
|
||||
#. Flavors can be designated as trusted using the :command:`openstack flavor
|
||||
set` command. In this example, the ``m1.tiny`` flavor is being set as
|
||||
trusted:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack flavor set --property trusted_host=trusted m1.tiny
|
||||
|
||||
#. You can request that your instance is run on a trusted host by specifying a
|
||||
trusted flavor when booting the instance:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack server create --flavor m1.tiny \
|
||||
--key-name myKeypairName --image myImageID newInstanceName
|
||||
|
||||
|
||||
.. figure:: figures/OpenStackTrustedComputePool2.png
|
||||
|
||||
Encrypt Compute metadata traffic
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**Enabling SSL encryption**
|
||||
|
||||
OpenStack supports encrypting Compute metadata traffic with HTTPS. Enable SSL
|
||||
encryption in the ``metadata_agent.ini`` file.
|
||||
|
||||
#. Enable the HTTPS protocol.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
nova_metadata_protocol = https
|
||||
|
||||
#. Determine whether insecure SSL connections are accepted for Compute metadata
|
||||
server requests. The default value is ``False``.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
nova_metadata_insecure = False
|
||||
|
||||
#. Specify the path to the client certificate.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
nova_client_cert = PATH_TO_CERT
|
||||
|
||||
#. Specify the path to the private key.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
nova_client_priv_key = PATH_TO_KEY
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
================================
|
||||
Configure Compute service groups
|
||||
================================
|
||||
|
||||
The Compute service must know the status of each compute node to effectively
|
||||
manage and use them. This can include events like a user launching a new VM,
|
||||
the scheduler sending a request to a live node, or a query to the ServiceGroup
|
||||
API to determine if a node is live.
|
||||
|
||||
When a compute worker running the nova-compute daemon starts, it calls the join
|
||||
API to join the compute group. Any service (such as the scheduler) can query
|
||||
the group's membership and the status of its nodes. Internally, the
|
||||
ServiceGroup client driver automatically updates the compute worker status.
|
||||
|
||||
.. _database-servicegroup-driver:
|
||||
|
||||
Database ServiceGroup driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
By default, Compute uses the database driver to track if a node is live. In a
|
||||
compute worker, this driver periodically sends a ``db update`` command to the
|
||||
database, saying “I'm OK” with a timestamp. Compute uses a pre-defined
|
||||
timeout (``service_down_time``) to determine if a node is dead.
|
||||
|
||||
The driver has limitations, which can be problematic depending on your
|
||||
environment. If a lot of compute worker nodes need to be checked, the database
|
||||
can be put under heavy load, which can cause the timeout to trigger, and a live
|
||||
node could incorrectly be considered dead. By default, the timeout is 60
|
||||
seconds. Reducing the timeout value can help in this situation, but you must
|
||||
also make the database update more frequently, which again increases the
|
||||
database workload.
|
||||
|
||||
The database contains data that is both transient (such as whether the node is
|
||||
alive) and persistent (such as entries for VM owners). With the ServiceGroup
|
||||
abstraction, Compute can treat each type separately.
|
||||
|
||||
.. _memcache-servicegroup-driver:
|
||||
|
||||
Memcache ServiceGroup driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The memcache ServiceGroup driver uses memcached, a distributed memory object
|
||||
caching system that is used to increase site performance. For more details, see
|
||||
`memcached.org <http://memcached.org/>`_.
|
||||
|
||||
To use the memcache driver, you must install memcached. You might already have
|
||||
it installed, as the same driver is also used for the OpenStack Object Storage
|
||||
and OpenStack dashboard. To install memcached, see the *Environment ->
|
||||
Memcached* section in the `Installation Tutorials and Guides
|
||||
<https://docs.openstack.org/project-install-guide/ocata>`_ depending on your
|
||||
distribution.
|
||||
|
||||
These values in the ``/etc/nova/nova.conf`` file are required on every node for
|
||||
the memcache driver:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
# Driver for the ServiceGroup service
|
||||
servicegroup_driver = "mc"
|
||||
|
||||
# Memcached servers. Use either a list of memcached servers to use for caching (list value),
|
||||
# or "<None>" for in-process caching (default).
|
||||
memcached_servers = <None>
|
||||
|
||||
# Timeout; maximum time since last check-in for up service (integer value).
|
||||
# Helps to define whether a node is dead
|
||||
service_down_time = 60
|
||||
|
|
@ -0,0 +1,259 @@
|
|||
====================
|
||||
Troubleshoot Compute
|
||||
====================
|
||||
|
||||
Common problems for Compute typically involve misconfigured networking or
|
||||
credentials that are not sourced properly in the environment. Also, most flat
|
||||
networking configurations do not enable :command:`ping` or :command:`ssh` from
|
||||
a compute node to the instances that run on that node. Another common problem
|
||||
is trying to run 32-bit images on a 64-bit compute node. This section shows
|
||||
you how to troubleshoot Compute.
|
||||
|
||||
Compute service logging
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Compute stores a log file for each service in ``/var/log/nova``. For example,
|
||||
``nova-compute.log`` is the log for the ``nova-compute`` service. You can set
|
||||
the following options to format log strings for the ``nova.log`` module in the
|
||||
``nova.conf`` file:
|
||||
|
||||
* ``logging_context_format_string``
|
||||
|
||||
* ``logging_default_format_string``
|
||||
|
||||
If the log level is set to ``debug``, you can also specify
|
||||
``logging_debug_format_suffix`` to append extra formatting. For information
|
||||
about what variables are available for the formatter, see `Formatter Objects
|
||||
<https://docs.python.org/library/logging.html#formatter-objects>`_.
|
||||
|
||||
You have two logging options for OpenStack Compute based on configuration
|
||||
settings. In ``nova.conf``, include the ``logfile`` option to enable logging.
|
||||
Alternatively you can set ``use_syslog = 1`` so that the nova daemon logs to
|
||||
syslog.
|
||||
|
||||
Guru Meditation reports
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A Guru Meditation report is sent by the Compute service upon receipt of the
|
||||
``SIGUSR2`` signal (``SIGUSR1`` before Mitaka). This report is a
|
||||
general-purpose error report that includes details about the current state of
|
||||
the service. The error report is sent to ``stderr``.
|
||||
|
||||
For example, if you redirect error output to ``nova-api-err.log`` using
|
||||
:command:`nova-api 2>/var/log/nova/nova-api-err.log`, resulting in the process
|
||||
ID 8675, you can then run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# kill -USR2 8675
|
||||
|
||||
This command triggers the Guru Meditation report to be printed to
|
||||
``/var/log/nova/nova-api-err.log``.
|
||||
|
||||
The report has the following sections:
|
||||
|
||||
* Package: Displays information about the package to which the process belongs,
|
||||
including version information.
|
||||
|
||||
* Threads: Displays stack traces and thread IDs for each of the threads within
|
||||
the process.
|
||||
|
||||
* Green Threads: Displays stack traces for each of the green threads within the
|
||||
process (green threads do not have thread IDs).
|
||||
|
||||
* Configuration: Lists all configuration options currently accessible through
|
||||
the CONF object for the current process.
|
||||
|
||||
For more information, see `Guru Meditation Reports
|
||||
<https://docs.openstack.org/developer/nova/devref/gmr.html>`_.
|
||||
|
||||
.. _compute-common-errors-and-fixes:
|
||||
|
||||
Common errors and fixes for Compute
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The `ask.openstack.org <http://ask.openstack.org>`_ site offers a place to ask
|
||||
and answer questions, and you can also mark questions as frequently asked
|
||||
questions. This section describes some errors people have posted previously.
|
||||
Bugs are constantly being fixed, so online resources are a great way to get the
|
||||
most up-to-date errors and fixes.
|
||||
|
||||
Credential errors, 401, and 403 forbidden errors
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
Missing credentials cause a ``403 forbidden`` error.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
To resolve this issue, use one of these methods:
|
||||
|
||||
#. Manual method
|
||||
|
||||
Gets the ``novarc`` file from the project ZIP file, saves existing
|
||||
credentials in case of override, and manually sources the ``novarc`` file.
|
||||
|
||||
#. Script method
|
||||
|
||||
Generates ``novarc`` from the project ZIP file and sources it for you.
|
||||
|
||||
When you run ``nova-api`` the first time, it generates the certificate
|
||||
authority information, including ``openssl.cnf``. If you start the CA services
|
||||
before this, you might not be able to create your ZIP file. Restart the
|
||||
services. When your CA information is available, create your ZIP file.
|
||||
|
||||
Also, check your HTTP proxy settings to see whether they cause problems with
|
||||
``novarc`` creation.
|
||||
|
||||
Instance errors
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
Sometimes a particular instance shows ``pending`` or you cannot SSH to it.
|
||||
Sometimes the image itself is the problem. For example, when you use flat
|
||||
manager networking, you do not have a DHCP server and certain images do not
|
||||
support interface injection; you cannot connect to them.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
To fix instance errors use an image that does support this method, such as
|
||||
Ubuntu, which obtains an IP address correctly with FlatManager network
|
||||
settings.
|
||||
|
||||
To troubleshoot other possible problems with an instance, such as an instance
|
||||
that stays in a spawning state, check the directory for the particular instance
|
||||
under ``/var/lib/nova/instances`` on the ``nova-compute`` host and make sure
|
||||
that these files are present:
|
||||
|
||||
* ``libvirt.xml``
|
||||
* ``disk``
|
||||
* ``disk-raw``
|
||||
* ``kernel``
|
||||
* ``ramdisk``
|
||||
* ``console.log``, after the instance starts.
|
||||
|
||||
If any files are missing, empty, or very small, the ``nova-compute`` service
|
||||
did not successfully download the images from the Image service.
|
||||
|
||||
Also check ``nova-compute.log`` for exceptions. Sometimes they do not appear in
|
||||
the console output.
|
||||
|
||||
Next, check the log file for the instance in the ``/var/log/libvirt/qemu``
|
||||
directory to see if it exists and has any useful error messages in it.
|
||||
|
||||
Finally, from the ``/var/lib/nova/instances`` directory for the instance, see
|
||||
if this command returns an error:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# virsh create libvirt.xml
|
||||
|
||||
Empty log output for Linux instances
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
You can view the log output of running instances from either the
|
||||
:guilabel:`Log` tab of the dashboard or the output of :command:`nova
|
||||
console-log`. In some cases, the log output of a running Linux instance will be
|
||||
empty or only display a single character (for example, the `?` character).
|
||||
|
||||
This occurs when the Compute service attempts to retrieve the log output of the
|
||||
instance via a serial console while the instance itself is not configured to
|
||||
send output to the console.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
To rectify this, append the following parameters to kernel arguments specified
|
||||
in the instance's boot loader:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
console=tty0 console=ttyS0,115200n8
|
||||
|
||||
Upon rebooting, the instance will be configured to send output to the Compute
|
||||
service.
|
||||
|
||||
Reset the state of an instance
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
Instances can remain in an intermediate state, such as ``deleting``.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
You can use the :command:`nova reset-state` command to manually reset the state
|
||||
of an instance to an error state. You can then delete the instance. For
|
||||
example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova reset-state c6bbbf26-b40a-47e7-8d5c-eb17bf65c485
|
||||
$ openstack server delete c6bbbf26-b40a-47e7-8d5c-eb17bf65c485
|
||||
|
||||
You can also use the ``--active`` parameter to force the instance back to an
|
||||
active state instead of an error state. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova reset-state --active c6bbbf26-b40a-47e7-8d5c-eb17bf65c485
|
||||
|
||||
Injection problems
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
Instances may boot slowly, or do not boot. File injection can cause this
|
||||
problem.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
To disable injection in libvirt, set the following in ``nova.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[libvirt]
|
||||
inject_partition = -2
|
||||
|
||||
.. note::
|
||||
|
||||
If you have not enabled the configuration drive and you want to make
|
||||
user-specified files available from the metadata server for to improve
|
||||
performance and avoid boot failure if injection fails, you must disable
|
||||
injection.
|
||||
|
||||
Disable live snapshotting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
Administrators using libvirt version ``1.2.2`` may experience problems with
|
||||
live snapshot creation. Occasionally, libvirt version ``1.2.2`` fails to create
|
||||
live snapshots under the load of creating concurrent snapshot.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
To effectively disable the libvirt live snapshotting, until the problem is
|
||||
resolved, configure the ``disable_libvirt_livesnapshot`` option. You can turn
|
||||
off the live snapshotting mechanism by setting up its value to ``True`` in the
|
||||
``[workarounds]`` section of the ``nova.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[workarounds]
|
||||
disable_libvirt_livesnapshot = True
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
.. _compute-trusted-pools.rst:
|
||||
|
||||
=====================
|
||||
System administration
|
||||
=====================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
manage-users.rst
|
||||
manage-volumes.rst
|
||||
flavors.rst
|
||||
default-ports.rst
|
||||
admin-password-injection.rst
|
||||
manage-the-cloud.rst
|
||||
manage-logs.rst
|
||||
root-wrap-reference.rst
|
||||
configuring-migrations.rst
|
||||
live-migration-usage.rst
|
||||
remote-console-access.rst
|
||||
service-groups.rst
|
||||
security.rst
|
||||
node-down.rst
|
||||
adv-config.rst
|
||||
|
||||
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:
|
||||
|
||||
**Services**
|
||||
|
||||
``nova-api``
|
||||
Receives XML requests and sends them to the rest of the system. A WSGI app
|
||||
routes and authenticates requests. Supports the EC2 and OpenStack APIs. A
|
||||
``nova.conf`` configuration file is created when Compute is installed.
|
||||
|
||||
``nova-cert``
|
||||
Manages certificates.
|
||||
|
||||
``nova-compute``
|
||||
Manages virtual machines. Loads a Service object, and exposes the public
|
||||
methods on ComputeManager through a Remote Procedure Call (RPC).
|
||||
|
||||
``nova-conductor``
|
||||
Provides database-access support for compute nodes (thereby reducing security
|
||||
risks).
|
||||
|
||||
``nova-consoleauth``
|
||||
Manages console authentication.
|
||||
|
||||
``nova-objectstore``
|
||||
A simple file-based storage system for images that replicates most of the S3
|
||||
API. It can be replaced with OpenStack Image service and either a simple
|
||||
image manager or OpenStack Object Storage as the virtual machine image
|
||||
storage facility. It must exist on the same node as ``nova-compute``.
|
||||
|
||||
``nova-network``
|
||||
Manages floating and fixed IPs, DHCP, bridging and VLANs. Loads a Service
|
||||
object which exposes the public methods on one of the subclasses of
|
||||
NetworkManager. Different networking strategies are available by changing the
|
||||
``network_manager`` configuration option to ``FlatManager``,
|
||||
``FlatDHCPManager``, or ``VLANManager`` (defaults to ``VLANManager`` if
|
||||
nothing is specified).
|
||||
|
||||
``nova-scheduler``
|
||||
Dispatches requests for new virtual machines to the correct node.
|
||||
|
||||
``nova-novncproxy``
|
||||
Provides a VNC proxy for browsers, allowing VNC consoles to access virtual
|
||||
machines.
|
||||
|
||||
.. 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. ``nova-network`` and
|
||||
``nova-scheduler`` also have drivers.
|
||||
|
|
@ -243,6 +243,13 @@ Metadata
|
|||
|
||||
user/vendordata
|
||||
|
||||
Administrators Guide
|
||||
====================
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
admin/index
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue