Remove compute pages
Remove the Compute pages as they are being migrated to the charm-guide. Add HTML redirects (and tests) as a consequence. Change-Id: Idf777582fcb902dcd1f603d04c8f872c579460ff
This commit is contained in:
Peter Matulis
parent
1fb631fbf9
commit
22ec0b52fd
|
|
@ -19,3 +19,7 @@ RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-poli
|
|||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-ha.html$ /charm-guide/$1/admin/ha.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-trilio-vault.html$ /charm-guide/$1/admin/trilio.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-masakari.html$ /charm-guide/$1/admin/instance-ha.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/nfv.html$ /charm-guide/$1/admin/compute/nfv.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/pci-passthrough.html$ /charm-guide/$1/admin/compute/pci-passthrough.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/nova-cells.html$ /charm-guide/$1/admin/compute/nova-cells.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/ironic.html$ /charm-guide/$1/admin/compute/ironic.html
|
||||
|
|
|
|||
|
|
@ -40,15 +40,6 @@ OpenStack Charms usage. To help improve it you can `file an issue`_ or
|
|||
keystone
|
||||
app-certificate-management
|
||||
|
||||
.. toctree::
|
||||
:caption: Compute
|
||||
:maxdepth: 1
|
||||
|
||||
ironic
|
||||
nova-cells
|
||||
pci-passthrough
|
||||
NFV <nfv>
|
||||
|
||||
.. toctree::
|
||||
:caption: Networking
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -1,442 +0,0 @@
|
|||
======
|
||||
Ironic
|
||||
======
|
||||
|
||||
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Ironic is an OpenStack project which provisions bare metal (as opposed to
|
||||
virtual) machines. This document describes deploying charmed OpenStack with
|
||||
Ironic. It is important to have `Upstream Ironic Documentation`_ as context.
|
||||
|
||||
.. note::
|
||||
|
||||
Ironic is supported by Charmed OpenStack starting with OpenStack Ussuri
|
||||
on Ubuntu 18.04.
|
||||
|
||||
Currently, charmed Ironic requires Neutron OpenVSwtich as the SDN and does
|
||||
not support OVN.
|
||||
|
||||
Charms
|
||||
~~~~~~
|
||||
|
||||
There are three Ironic charms:
|
||||
|
||||
* ironic-api (Ironic API)
|
||||
* ironic-conductor (Ironic Conductor)
|
||||
* neutron-api-plugin-ironic (Neutron API Plugin Ironic API)
|
||||
|
||||
* SDN plugin subordinate to Neutron API
|
||||
|
||||
|
||||
Deployment considerations
|
||||
-------------------------
|
||||
|
||||
See `Example Bundle`_ for a known working configuration. The bundle deploys an
|
||||
instantiation of nova-compute dedicated to Ironic. The ``virt-type`` is set to
|
||||
'ironic' in order to indicate to Nova that bare metal deployments are available.
|
||||
|
||||
.. note::
|
||||
|
||||
The Ironic instantiation of nova-compute does not require compute or network
|
||||
resources and can therefore be deployed in a LXD container.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
nova-ironic:
|
||||
charm: cs:~openstack-charmers-next/nova-compute
|
||||
series: focal
|
||||
num_units: 1
|
||||
bindings:
|
||||
"": *oam-space
|
||||
options:
|
||||
enable-live-migration: false
|
||||
enable-resize: false
|
||||
openstack-origin: *openstack-origin
|
||||
virt-type: ironic
|
||||
to:
|
||||
- "lxd:3"
|
||||
|
||||
Network topology
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The primary consideration for a charmed OpenStack deployment with Ironic is the
|
||||
network topology. In a typical OpenStack deployment one will have a single
|
||||
provider network for the "external" network where floating IPs and virtual
|
||||
router interfaces will be instantiated. Some topologies may also include an
|
||||
"internal" provider network. For the charmed Ironic deployment we recommend a
|
||||
dedicated provider network (i.e. physnet) for bare metal deployment. There are
|
||||
other ML2 solutions that support the bare metal VNIC type. See the
|
||||
*enabled-network-interfaces* setting on the ironic-conductor charm.
|
||||
|
||||
.. note::
|
||||
|
||||
This dedicated network will not be managed by MAAS as Neutron will provide
|
||||
DHCP in order to enable Ironic to respond to bare metal iPXE requests.
|
||||
|
||||
In the examples below the network node will have three interfaces:
|
||||
|
||||
* enp1s0: OAM network (network the infrastructure is deployed on)
|
||||
* enp7s0: External - physnet1
|
||||
* enp8s0: Deployment - phystnet2
|
||||
|
||||
See the documentation in this guide for `Neutron networking deployment`_.
|
||||
|
||||
In the bundle the relevant settings for neutron-gateway are:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
neutron-gateway
|
||||
options:
|
||||
bridge-mappings: physnet1:br-ex physnet2:br-deployment
|
||||
data-port: br-ex:enp7s0 br-deployment:enp8s0
|
||||
|
||||
The view from outside OpenStack will look something like:
|
||||
|
||||
.. figure:: ./media/ironic-external-network-topology.png
|
||||
:scale: 100%
|
||||
:alt: Internal topology view
|
||||
|
||||
The view from inside OpenStack will look something like:
|
||||
|
||||
.. figure:: ./media/ironic-internal-network-topology.png
|
||||
:scale: 100%
|
||||
:alt: Internal topology view
|
||||
|
||||
.. note::
|
||||
|
||||
Ironic conductor (in the control plane cloud above) requires network
|
||||
connectivity both to the bare metal nodes on the bare metal deployment
|
||||
network and to the power management interfaces for the bare metal nodes (not
|
||||
shown in the diagram above).
|
||||
|
||||
In addition, the baremetal nodes themselves require network connectivity to
|
||||
the ironic-api to acquire metadata and the object-store (Swift or RadosGW)
|
||||
to acquire images.
|
||||
|
||||
Swift backend for Glance
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In order to use the direct deployment method (see `Ironic deploy interfaces`_)
|
||||
we need to have Glance store bare metal images in a Swift backend to make them
|
||||
accessible by bare metal servers.
|
||||
|
||||
Add a relation between `glance`_ and `ceph-radosgw`_:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju add relation ceph-radosgw:object-store glance:object-store
|
||||
|
||||
Post-deployment configuration
|
||||
-----------------------------
|
||||
|
||||
Follow the rest of this deployment guide for the typical post-deployment
|
||||
configuration. See `Configure OpenStack`_. The following is specific to Ironic.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
The rest of this section provides an example of a bare metal setup with IPv4
|
||||
and a dedicated provider network (physnet2).
|
||||
|
||||
Create the bare metal deployment network
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Create the bare metal deployment network on *physnet2*.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack network create \
|
||||
--share \
|
||||
--provider-network-type flat \
|
||||
--provider-physical-network physnet2 \
|
||||
deployment
|
||||
|
||||
openstack subnet create \
|
||||
--network deployment \
|
||||
--dhcp \
|
||||
--subnet-range 10.0.0.0/24 \
|
||||
--gateway 10.0.0.1 \
|
||||
--ip-version 4 \
|
||||
--allocation-pool start=10.0.0.100,end=10.0.0.254 \
|
||||
deployment
|
||||
|
||||
export NETWORK_ID=$(openstack network show deployment --format json | jq -r .id)
|
||||
|
||||
Building Ironic images
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We will need three types of images for bare metal deployments: two for the iPXE
|
||||
process (initramfs and kernel) and at least one bare metal image for the OS one
|
||||
wishes to deploy.
|
||||
|
||||
Ironic depends on having an image with the ironic-python-agent (IPA) service
|
||||
running on it for controlling and deploying bare metal nodes. Building the
|
||||
images can be done using the `Ironic Python Agent Builder`_. This step can be
|
||||
done once and the images stored for future use.
|
||||
|
||||
IP install prerequisites
|
||||
________________________
|
||||
|
||||
Build on Ubuntu 20.04 LTS (Focal) or later. If ``disk-image-builder`` is run on an
|
||||
older version you may see the following error:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
INFO diskimage_builder.block_device.utils [-] Calling [sudo kpartx -uvs /dev/loop7]
|
||||
ERROR diskimage_builder.block_device.blockdevice [-] Create failed; rollback initiated
|
||||
|
||||
Install the ``disk-image-builder`` and ``ironic-python-agent-builder``:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
pip3 install --user diskimage-builder ironic-python-agent-builder
|
||||
|
||||
Build the IPA deploy images
|
||||
___________________________
|
||||
|
||||
These images will be used to PXE boot the bare metal node for installation.
|
||||
|
||||
Create a folder for the images:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
export IMAGE_DIR="$HOME/images"
|
||||
mkdir -p $IMAGE_DIR
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
ironic-python-agent-builder ubuntu \
|
||||
-o $IMAGE_DIR/ironic-python-agent
|
||||
|
||||
Build the bare metal OS images
|
||||
______________________________
|
||||
|
||||
These images will be deployed to the bare metal server.
|
||||
|
||||
Generate Bionic and Focal images:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
for release in bionic focal
|
||||
do
|
||||
export DIB_RELEASE=$release
|
||||
disk-image-create --image-size 5 \
|
||||
ubuntu vm dhcp-all-interfaces \
|
||||
block-device-efi \
|
||||
-o $IMAGE_DIR/baremetal-ubuntu-$release
|
||||
done
|
||||
|
||||
Command argument breakdown:
|
||||
|
||||
* ubuntu: builds an Ubuntu image
|
||||
* `vm`_: The image will be a "whole disk" image
|
||||
* `dhcp-all-interfaces`_: Will use DHCP on all interfaces
|
||||
* `block-device-efi`_: Creates a GPT partition table,
|
||||
suitable for booting an EFI system
|
||||
|
||||
Upload images to Glance
|
||||
_______________________
|
||||
|
||||
Convert images to raw. Not necessarily needed, but this will save CPU cycles at
|
||||
deployment time:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
for release in bionic focal
|
||||
do
|
||||
qemu-img convert -f qcow2 -O raw \
|
||||
$IMAGE_DIR/baremetal-ubuntu-$release.qcow2 \
|
||||
$IMAGE_DIR/baremetal-ubuntu-$release.img
|
||||
rm $IMAGE_DIR/baremetal-ubuntu-$release.qcow2
|
||||
done
|
||||
|
||||
Upload OS images. Operating system images need to be uploaded to the Swift
|
||||
backend if we plan to use direct deploy mode:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
for release in bionic focal
|
||||
do
|
||||
glance image-create \
|
||||
--store swift \
|
||||
--name baremetal-${release} \
|
||||
--disk-format raw \
|
||||
--container-format bare \
|
||||
--file $IMAGE_DIR/baremetal-ubuntu-${release}.img
|
||||
done
|
||||
|
||||
Upload IPA images:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
glance image-create \
|
||||
--store swift \
|
||||
--name deploy-vmlinuz \
|
||||
--disk-format aki \
|
||||
--container-format aki \
|
||||
--visibility public \
|
||||
--file $IMAGE_DIR/ironic-python-agent.kernel
|
||||
|
||||
glance image-create \
|
||||
--store swift \
|
||||
--name deploy-initrd \
|
||||
--disk-format ari \
|
||||
--container-format ari \
|
||||
--visibility public \
|
||||
--file $IMAGE_DIR/ironic-python-agent.initramfs
|
||||
|
||||
Save the image IDs as variables for later:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
export DEPLOY_VMLINUZ_UUID=$(openstack image show deploy-vmlinuz --format json| jq -r .id)
|
||||
export DEPLOY_INITRD_UUID=$(openstack image show deploy-initrd --format json| jq -r .id)
|
||||
|
||||
Create flavors for bare metal
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Flavor characteristics like memory and disk are not used for scheduling. Disk
|
||||
size is used to determine the root partition size of the bare metal node. If in
|
||||
doubt, make the DISK_GB variable smaller than the size of the disks you are
|
||||
deploying to. The ``cloud-init`` process will take care of expanding the
|
||||
partition on first boot.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
# Match these to your HW
|
||||
export RAM_MB=4096
|
||||
export CPU=4
|
||||
export DISK_GB=6
|
||||
export FLAVOR_NAME="baremetal-small"
|
||||
|
||||
Create a flavor and set a resource class. We will add the same resource class
|
||||
to the node we will be enrolling later. The scheduler will use the resource
|
||||
class to find a node that matches the flavor:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack flavor create --ram $RAM_MB --vcpus $CPU --disk $DISK_GB $FLAVOR_NAME
|
||||
openstack flavor set --property resources:CUSTOM_BAREMETAL_SMALL=1 $FLAVOR_NAME
|
||||
|
||||
Disable scheduling based on standard flavor properties:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack flavor set --property resources:VCPU=0 $FLAVOR_NAME
|
||||
openstack flavor set --property resources:MEMORY_MB=0 $FLAVOR_NAME
|
||||
openstack flavor set --property resources:DISK_GB=0 $FLAVOR_NAME
|
||||
|
||||
.. note::
|
||||
|
||||
Ultimately, the end user will receive the whole bare metal machine. Its
|
||||
resources will not be limited in any way. The above settings orient the
|
||||
scheuduler to bare metal machines.
|
||||
|
||||
Enroll a node
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. note::
|
||||
|
||||
Virutally all of the settings below are specific to one's environment. The
|
||||
following is provided as an example.
|
||||
|
||||
Create the node and save the UUID:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
export NODE_NAME01="ironic-node01"
|
||||
export NODE_NAME02="ironic-node02"
|
||||
openstack baremetal node create --name $NODE_NAME01 \
|
||||
--driver ipmi \
|
||||
--deploy-interface direct \
|
||||
--driver-info ipmi_address=10.10.0.1 \
|
||||
--driver-info ipmi_username=admin \
|
||||
--driver-info ipmi_password=Passw0rd \
|
||||
--driver-info deploy_kernel=$DEPLOY_VMLINUZ_UUID \
|
||||
--driver-info deploy_ramdisk=$DEPLOY_INITRD_UUID \
|
||||
--driver-info cleaning_network=$NETWORK_ID \
|
||||
--driver-info provisioning_network=$NETWORK_ID \
|
||||
--property capabilities='boot_mode:uefi' \
|
||||
--resource-class baremetal-small \
|
||||
--property cpus=4 \
|
||||
--property memory_mb=4096 \
|
||||
--property local_gb=20
|
||||
|
||||
openstack baremetal node create --name $NODE_NAME02 \
|
||||
--driver ipmi \
|
||||
--deploy-interface direct \
|
||||
--driver-info ipmi_address=10.10.0.1 \
|
||||
--driver-info ipmi_username=admin \
|
||||
--driver-info ipmi_password=Passw0rd \
|
||||
--driver-info deploy_kernel=$DEPLOY_VMLINUZ_UUID \
|
||||
--driver-info deploy_ramdisk=$DEPLOY_INITRD_UUID \
|
||||
--driver-info cleaning_network=$NETWORK_ID \
|
||||
--driver-info provisioning_network=$NETWORK_ID \
|
||||
--resource-class baremetal-small \
|
||||
--property capabilities='boot_mode:uefi' \
|
||||
--property cpus=4 \
|
||||
--property memory_mb=4096 \
|
||||
--property local_gb=25
|
||||
|
||||
|
||||
export NODE_UUID01=$(openstack baremetal node show $NODE_NAME01 --format json | jq -r .uuid)
|
||||
export NODE_UUID02=$(openstack baremetal node show $NODE_NAME02 --format json | jq -r .uuid)
|
||||
|
||||
Create a port for the node. The MAC address must match the MAC address of the
|
||||
network interface attached to the bare metal server. Make sure to map the port
|
||||
to the proper physical network:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack baremetal port create 52:54:00:6a:79:e6 \
|
||||
--node $NODE_UUID01 \
|
||||
--physical-network=physnet2
|
||||
|
||||
openstack baremetal port create 52:54:00:c5:00:e8 \
|
||||
--node $NODE_UUID02 \
|
||||
--physical-network=physnet2
|
||||
|
||||
Make the nodes available for deployment
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack baremetal node manage $NODE_UUID01
|
||||
openstack baremetal node provide $NODE_UUID01
|
||||
|
||||
openstack baremetal node manage $NODE_UUID02
|
||||
openstack baremetal node provide $NODE_UUID02
|
||||
|
||||
|
||||
At this point, a bare metal node list will show the bare metal machines going into a cleaning phase. If that is successful, they bare metal nodes will become ``available``.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack baremetal node list
|
||||
|
||||
|
||||
Boot a bare metal machine
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openstack server create \
|
||||
--flavor baremetal-small \
|
||||
--key-name mykey test
|
||||
|
||||
.. LINKS
|
||||
.. _Neutron networking deployment: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/ussuri/install-openstack.html#neutron-networking
|
||||
.. _Upstream Ironic Documentation: https://docs.openstack.org/ironic/latest/
|
||||
.. _Example Bundle: https://github.com/thedac/openstack-bundles/blob/ironic-deployment/development/openstack-ironic-focal-ussuri/bundle.yaml
|
||||
.. _Building deploy ramdisk: https://docs.openstack.org/ironic/latest/install/deploy-ramdisk.html
|
||||
.. _Ironic Python Agent Builder: https://docs.openstack.org/ironic-python-agent-builder/latest/
|
||||
.. _vm: https://docs.openstack.org/diskimage-builder/latest/elements/vm/README.html
|
||||
.. _dhcp-all-interfaces: https://docs.openstack.org/diskimage-builder/latest/elements/dhcp-all-interfaces/README.html
|
||||
.. _block-device-efi: https://docs.openstack.org/diskimage-builder/latest/elements/block-device-efi/README.html
|
||||
.. _ironic deploy interfaces: https://docs.openstack.org/ironic/latest/admin/interfaces/deploy.html
|
||||
.. _glance: https://charmhub.io/glance
|
||||
.. _ceph-radosgw: https://charmhub.io/ceph-radosgw
|
||||
.. _Configure OpenStack: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/configure-openstack.html
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 106 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
|
|
@ -1,80 +0,0 @@
|
|||
======================================
|
||||
Network Functions Virtualization (NFV)
|
||||
======================================
|
||||
|
||||
The nova-compute charm (in conjunction with the nova-cloud-controller and
|
||||
neutron-api charms) supports compute nodes configured for the use in Telco NFV
|
||||
deployments, specifically the following configuration options (YAML excerpt):
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
nova-compute:
|
||||
hugepages: 60%
|
||||
vcpu-pin-set: "^0,^2"
|
||||
reserved-host-memory: 1024
|
||||
pci-passthrough-whitelist: {"vendor_id":"1137","product_id":"0071","address":"*:0a:00.*","physical_network":"physnet1"}
|
||||
|
||||
In this example, compute nodes will be configured with 60% of available RAM for
|
||||
hugepage use (decreasing memory fragmentation in virtual machines, improving
|
||||
performance), and Nova will be configured to reserve CPU cores 0 and 2 and
|
||||
1024M of RAM for host usage and use the supplied PCI device whitelist as PCI
|
||||
devices that as consumable by virtual machines, including any mapping to
|
||||
underlying provider network names (used for SR-IOV VF/PF port scheduling with
|
||||
Nova and Neutron's SR-IOV support).
|
||||
|
||||
The ``vcpu-pin-set`` configuration option is a comma-separated list of physical
|
||||
CPU numbers that virtual CPUs can be allocated to by default. Each element
|
||||
should be either a single CPU number, a range of CPU numbers, or a caret
|
||||
followed by a CPU number to be excluded from a previous range. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
vcpu-pin-set: "4-12,^8,15"
|
||||
|
||||
The pci-passthrough-whitelist configuration must be specified as follows:
|
||||
|
||||
A JSON dictionary which describe a whitelisted PCI device. It should take the
|
||||
following format:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
["device_id": "<id>",] ["product_id": "<id>",]
|
||||
["address": "[[[[<domain>]:]<bus>]:][<slot>][.[<function>]]" |
|
||||
"devname": "PCI Device Name",]
|
||||
{"tag": "<tag_value>",}
|
||||
|
||||
Where '[' indicates zero or one occurrences, '{' indicates zero or multiple
|
||||
occurrences, and '|' mutually exclusive options. Note that any missing fields
|
||||
are automatically wildcarded. Valid examples are:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pci-passthrough-whitelist: {"devname":"eth0", "physical_network":"physnet"}
|
||||
|
||||
pci-passthrough-whitelist: {"address":"*:0a:00.*"}
|
||||
|
||||
pci-passthrough-whitelist: {"address":":0a:00.", "physical_network":"physnet1"}
|
||||
|
||||
pci-passthrough-whitelist: {"vendor_id":"1137", "product_id":"0071"}
|
||||
|
||||
pci-passthrough-whitelist: {"vendor_id":"1137", "product_id":"0071", "address": "0000:0a:00.1", "physical_network":"physnet1"}
|
||||
|
||||
The following is invalid, as it specifies mutually exclusive options:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pci-passthrough-whitelist: {"devname":"eth0", "physical_network":"physnet", "address":"*:0a:00.*"}
|
||||
|
||||
A JSON list of JSON dictionaries corresponding to the above format. For
|
||||
example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
pci-passthrough-whitelist: [{"product_id":"0001", "vendor_id":"8086"}, {"product_id":"0002", "vendor_id":"8086"}]
|
||||
|
||||
The `OpenStack advanced networking documentation`_ provides further details on
|
||||
whitelist configuration and how to create instances with Neutron ports wired to
|
||||
SR-IOV devices.
|
||||
|
||||
.. LINKS
|
||||
.. _OpenStack advanced networking documentation: https://docs.openstack.org/neutron/wallaby/admin/config-sriov.html
|
||||
|
|
@ -1,271 +0,0 @@
|
|||
==========
|
||||
Nova Cells
|
||||
==========
|
||||
|
||||
Overview
|
||||
++++++++
|
||||
|
||||
|
||||
As of the 18.11 charm release, with OpenStack Rocky and later, multiple nova
|
||||
cells can be created when deploying a cloud or an existing deployment can be
|
||||
extended to add additional cells.
|
||||
|
||||
Prior to Rocky, and since Pike, all OpenStack charm deployments have two
|
||||
cells: cell0 which is used to store instances which failed to get scheduled
|
||||
and cell1 which is an active compute cell. Additional cells are not supported
|
||||
by the charms prior to Rocky.
|
||||
|
||||
Nova Cells v2 Topology
|
||||
++++++++++++++++++++++
|
||||
|
||||
Nova cells v2 is entirely distinct from Nova cells v1. V1 has been deprecated
|
||||
and special care should be taken when reading nova documentation to ensure that
|
||||
it is v2 specific.
|
||||
|
||||
.. note::
|
||||
|
||||
This is a *Nova* cell, other services such as Neutron, Glance etc are not
|
||||
cell aware.
|
||||
|
||||
The Super Conductor
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For a deployment with multiple cells a dedicated conductor must be run for the
|
||||
API-level services. This conductor will have access to the API database and a
|
||||
dedicated message queue. This is called the super conductor to distinguish its
|
||||
place and purpose from the per-cell conductor nodes
|
||||
(See `Cells Layout <https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#multiple-cells>`_.). The existing *nova-cloud-controller* charm already performs
|
||||
the role of the super conductor for the whole cloud and, in addition, acts as a
|
||||
cell conductor for cell1.
|
||||
|
||||
|
||||
nova-cell-controller charm
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A new *nova-cell-controller* charm has been created. This charm just runs the
|
||||
*nova-conductor* service and proxies some charm information, such as ssh keys,
|
||||
between the cell compute nodes and the super-conductor. An instance of
|
||||
*nova-cell-controller* is required per additional cell.
|
||||
|
||||
Using application names to distinguish between cells
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Each cell requires the following charms:
|
||||
|
||||
* nova-cell-controller
|
||||
* rabbitmq-server
|
||||
* mysql-innodb-cluster
|
||||
* nova-compute
|
||||
|
||||
.. note::
|
||||
|
||||
Prior to Ubuntu 20.04 LTS (Focal) the percona-cluster charm (as opposed to
|
||||
mysql-innodb-cluster) is used for the cloud database
|
||||
(see :doc:`percona-cluster charm: series upgrade to focal
|
||||
<percona-series-upgrade-to-focal>`). The `corresponding page in the Train
|
||||
release`_ of this guide covers percona-cluster instructions.
|
||||
|
||||
To allow each application to be configured differently between cells and to
|
||||
be able to distinguish which instance of an application goes with which cell it
|
||||
is useful to add the cell name to the service name when deploying the
|
||||
components.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju deploy nova-compute nova-compute-cell4
|
||||
|
||||
Rabbit for Neutron
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
One of the motivations for using cells is to help with scaling to a large
|
||||
number of compute nodes. While not a cells feature (nor a new feature) it is
|
||||
worth pointing out that the charms support breaking Neutron message traffic
|
||||
out onto a separate broker.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju add-relation neutron-api:amqp rabbitmq-server-neutron:amqp
|
||||
juju add-relation neutron-gateway:amqp rabbitmq-server-neutron:amqp
|
||||
juju add-relation neutron-openvswitch:amqp rabbitmq-server-neutron:amqp
|
||||
juju add-relation ceilometer:amqp-listener rabbitmq-server-neutron:amqp
|
||||
|
||||
Adding A New Cell to an Existing Deployment
|
||||
+++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
In an existing deployment cell1 already exists as do the services to support
|
||||
it. To add 'cell2' to this deployment the new cell applications need to be
|
||||
deployed and related to the existing applications.
|
||||
|
||||
Add the four cell applications:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju deploy -n 3 ch:mysql-innodb-cluster mysql-innodb-cluster-cell2
|
||||
juju deploy ch:mysql-router nova-cell-controller-cell2-mysql-router
|
||||
juju deploy ch:rabbitmq-server rabbitmq-server-nova-cell2
|
||||
juju deploy ch:nova-compute nova-compute-cell2
|
||||
juju deploy ch:nova-cell-controller --config cell-name='cell2' nova-cell-controller-cell2
|
||||
|
||||
.. note::
|
||||
|
||||
mysql-innodb-cluster charm deploys HA MySQL database cluster therefore it requires at least three units.
|
||||
|
||||
Relate the new cell applications to each other:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju add-relation nova-compute-cell2:amqp rabbitmq-server-nova-cell2:amqp
|
||||
juju add-relation nova-cell-controller-cell2:amqp rabbitmq-server-nova-cell2:amqp
|
||||
juju add-relation nova-cell-controller-cell2:shared-db nova-cell-controller-cell2-mysql-router:shared-db
|
||||
juju add-relation nova-cell-controller-cell2-mysql-router:db-router mysql-innodb-cluster-cell2:db-router
|
||||
juju add-relation nova-cell-controller-cell2:cloud-compute nova-compute-cell2:cloud-compute
|
||||
|
||||
Relate the super conductor to the new cell:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju add-relation nova-cloud-controller:nova-cell-api nova-cell-controller-cell2:nova-cell-compute
|
||||
juju add-relation nova-cloud-controller:amqp-cell rabbitmq-server-nova-cell2:amqp
|
||||
juju add-relation nova-cloud-controller:shared-db-cell nova-cell-controller-cell2-mysql-router:shared-db
|
||||
|
||||
Relate the new cell to network, image and identity services:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju add-relation nova-compute-cell2:neutron-plugin neutron-openvswitch:neutron-plugin
|
||||
juju add-relation nova-compute-cell2:image-service glance:image-service
|
||||
juju add-relation nova-cell-controller-cell2:identity-credentials keystone:identity-credentials
|
||||
juju add-relation nova-compute-cell2:cloud-credentials keystone:identity-credentials
|
||||
|
||||
Relate the new cell to telemetry services.
|
||||
|
||||
.. note::
|
||||
|
||||
The ceilometer charm has an *amqp* and an *amqp-listerner* interface.
|
||||
ceilometer will listen and post messages to the broker related to the
|
||||
*amqp* interface. It will only listen to messages posted to the broker(s)
|
||||
related to the *amqp-listener*. Therefore services that consume messages
|
||||
from ceilometer, such as aodh, should be related to the broker associated
|
||||
with ceilometers *amqp* interface.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju add-relation ceilometer:amqp-listener rabbitmq-server-nova-cell2:amqp
|
||||
juju add-relation ceilometer-agent:nova-ceilometer nova-compute-cell2:nova-ceilometer
|
||||
|
||||
New Deployments
|
||||
+++++++++++++++
|
||||
|
||||
For all cell deployments ensure the following:
|
||||
|
||||
* Application naming scheme such that the cell an application belongs to is
|
||||
clear.
|
||||
* Naming the central message broker such that its purpose is clear
|
||||
eg rabbitmq-server-general
|
||||
|
||||
If cells are being used primarily to help with a large scale out of compute
|
||||
resources then in addition:
|
||||
|
||||
* Do not relate compute nodes to the *nova-cloud-controller*
|
||||
* Have a separate message broker for Neutron.
|
||||
|
||||
Below is an example of an overlay which can be used when doing a fresh deploy
|
||||
to add a second cell:
|
||||
|
||||
.. code:: yaml
|
||||
|
||||
applications:
|
||||
mysql-innodb-cluster-cell2:
|
||||
charm: ch:mysql-innodb-cluster
|
||||
num_units: 3
|
||||
options:
|
||||
max-connections: 1000
|
||||
nova-cell-controller-cell2-mysql-router:
|
||||
charm: ch:mysql-router
|
||||
num_units: 1
|
||||
options:
|
||||
base-port: 3316
|
||||
nova-cell-controller-cell2:
|
||||
charm: ch:nova-cell-controller
|
||||
num_units: 1
|
||||
options:
|
||||
cell-name: "cell2"
|
||||
nova-compute-cell2:
|
||||
charm: ch:nova-compute
|
||||
num_units: 1
|
||||
constraints: mem=4G
|
||||
options:
|
||||
config-flags: default_ephemeral_format=ext4
|
||||
enable-live-migration: true
|
||||
enable-resize: true
|
||||
migration-auth-type: ssh
|
||||
rabbitmq-server-nova-cell2:
|
||||
charm: ch:rabbitmq-server
|
||||
num_units: 1
|
||||
relations:
|
||||
- - nova-compute-cell2:neutron-plugin
|
||||
- neutron-openvswitch:neutron-plugin
|
||||
- - nova-compute-cell2:image-service
|
||||
- glance:image-service
|
||||
- - nova-compute-cell2:cloud-credentials
|
||||
- keystone:identity-credentials
|
||||
- - nova-cell-controller-cell2:identity-credentials
|
||||
- keystone:identity-credentials
|
||||
- - nova-cloud-controller:amqp-cell
|
||||
- rabbitmq-server-nova-cell2:amqp
|
||||
- - nova-cloud-controller:nova-cell-api
|
||||
- nova-cell-controller-cell2:nova-cell-compute
|
||||
- - nova-cloud-controller:shared-db-cell
|
||||
- nova-cell-controller-cell2-mysql-router:shared-db
|
||||
- - nova-compute-cell2:amqp
|
||||
- rabbitmq-server-nova-cell2:amqp
|
||||
- - nova-cell-controller-cell2:amqp
|
||||
- rabbitmq-server-nova-cell2:amqp
|
||||
- - nova-cell-controller-cell2:shared-db
|
||||
- nova-cell-controller-cell2-mysql-router:shared-db
|
||||
- - nova-cell-controller-cell2-mysql-router:db-router
|
||||
- mysql-innodb-cluster-cell2:db-router
|
||||
- - nova-cell-controller-cell2:cloud-compute
|
||||
- nova-compute-cell2:cloud-compute
|
||||
- - ceilometer:amqp-listener
|
||||
- rabbitmq-server-nova-cell2::amqp
|
||||
- - ceilometer-agent:nova-ceilometer
|
||||
- nova-compute-cell2::nova-ceilometer
|
||||
|
||||
Targeting instances at a cell
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Instances can be targeted at a specific cell by manually maintaining host
|
||||
aggregates and corresponding flavors which target those host aggregates. For
|
||||
example, assume *cell2* has one compute host *juju-250b86-prod-19*. Create a
|
||||
host aggregate for *cell2* and add the compute host into it.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
openstack aggregate create --property cell=cell2 ag_cell2
|
||||
openstack aggregate add host ag_cell2 juju-250b86-prod-19
|
||||
|
||||
|
||||
Now create a flavor that targets that cell.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
openstack flavor create --id 5 --ram 2048 --disk 10 --ephemeral 0 --vcpus 1 --public --property cell=cell2 m1.cell2.small
|
||||
|
||||
Finally, enable the *AggregateInstanceExtraSpecsFilter*
|
||||
|
||||
.. code:: bash
|
||||
|
||||
FILTERS=$(juju config nova-cloud-controller scheduler-default-filters)
|
||||
juju config nova-cloud-controller scheduler-default-filters="${FILTERS},AggregateInstanceExtraSpecsFilter"
|
||||
|
||||
Now instances that use the *m1.cell2.small* filter will land on cell2 compute
|
||||
hosts.
|
||||
|
||||
.. note::
|
||||
|
||||
These host aggregates need to be manually updated when compute nodes are
|
||||
added to the cell.
|
||||
|
||||
.. LINKS
|
||||
.. _corresponding page in the Train release: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/train/app-nova-cells.html
|
||||
|
|
@ -1,267 +0,0 @@
|
|||
===============
|
||||
PCI Passthrough
|
||||
===============
|
||||
|
||||
Introduction
|
||||
++++++++++++
|
||||
|
||||
PCI pass through allows compute nodes to pass a physical PCI device to a hosted
|
||||
VM. This can be used for direct access to a PCI device inside the VM. For
|
||||
example a GPU or direct access to a physical network interface. The OpenStack
|
||||
charms fully support this feature. The following will document deployment and
|
||||
configuration of the feature. This document will focus on using OpenStack
|
||||
charms, Juju and MAAS. It is worth familiarizing yourself with the generic
|
||||
OpenStack Nova documentation at
|
||||
https://docs.openstack.org/nova/latest/admin/pci-passthrough.html.
|
||||
|
||||
|
||||
Example Hardware
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
This document will assume a MAAS environment with compute hosts that have two
|
||||
GPUs per physical host. In this case, a Quadro P5000 with PCI IDs **83:00.0**
|
||||
and **84:00.0** and vendor and product ids of **10de:1bb0**.
|
||||
|
||||
lspci output:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
lspci -nn | grep VGA
|
||||
83:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1bb0] (rev a1) (prog-if 00 [VGA controller])
|
||||
84:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1bb0] (rev a1) (prog-if 00 [VGA controller])
|
||||
|
||||
|
||||
Infrastructure
|
||||
++++++++++++++
|
||||
|
||||
.. note::
|
||||
To passthrough PCI devices IOMMU must be enabled for the hardware. Depending
|
||||
on the hardware vendor (Intel or AMD) enable the virtualisation feature in
|
||||
BIOS and set the correct kernel parameter as described bellow (intel_iommu,
|
||||
amd_iommu).
|
||||
|
||||
|
||||
|
||||
|
||||
Blacklisting the PCI device
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are certain cases, particularly for GPUs, where we must blacklist the PCI
|
||||
device at the physical host so that its kernel does not load drivers. i.e. stop
|
||||
the physical host's kernel from loading NVIDIA or nouveau drivers for the GPU.
|
||||
The host must be able to cleanly pass the device to libvirt.
|
||||
|
||||
|
||||
Most PCI devices can be hot unbound and then bound via vfio-pci or the pci-stub
|
||||
legacy method and therefore do not require blacklisting. However, GPU devices
|
||||
do require blacklisting. This documentation covers the GPU case. The
|
||||
blacklisting documentation is based on the following:
|
||||
https://www.pugetsystems.com/labs/articles/Multiheaded-NVIDIA-Gaming-using-Ubuntu-14-04-KVM-585/
|
||||
|
||||
|
||||
MAAS
|
||||
~~~~
|
||||
|
||||
MAAS tags can also send kernel boot parameters. The tag will therefore serve
|
||||
two purposes: to select physical hosts which have PCI devices installed and to
|
||||
pass kernel parameters in order to blacklist the PCI device stopping the kernel
|
||||
from loading a driver for the device.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
maas $MASS_PROFILE tags create name="pci-pass" comment="PCI Passthrough kernel parameters" kernel_opts="intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1"
|
||||
|
||||
.. note::
|
||||
A MAAS host with more than one tag that sets kernel parameters will execute only one set. Good practice is to only have one kernel parameter setting tag on any given host to avoid confusion.
|
||||
|
||||
In Target Changes
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The MAAS tag and kernel parameters are only half the blacklisting solution. We
|
||||
also need the host to actively check the blacklisting. This requires setting up
|
||||
some configuration at deploy time. There are a few options on how to accomplish
|
||||
this, however, this document will use cloud init configuration at the Juju
|
||||
model level.
|
||||
|
||||
For other options to customize the deployed host see:
|
||||
https://docs.maas.io/2.5/en/nodes-custom
|
||||
|
||||
Juju can customize the host configuration using model level configuration for
|
||||
cloudinit-userdata. We will leverage this feature to do the final configuration
|
||||
of the physical host.
|
||||
|
||||
.. note::
|
||||
|
||||
Model level cloudinit userdata will get executed on all "machines" in a model.
|
||||
This includes physical hosts and containers. Take care to ensure any
|
||||
customization scripts will work in all cases.
|
||||
|
||||
Determine the vendor and product ID of the PCI device from lspci. In our case
|
||||
the GPU's is **10de:1bb0**.
|
||||
|
||||
Determine the PCI device IDs of the PCI device from lspci. In our case the
|
||||
GPU's are **83:00.0** and **84:00.0**.
|
||||
|
||||
Determine which driver we are blacklisting. This information can be found in
|
||||
the lspci output "Kernel modules." In our case **nvidiafb** and **nouveau**.
|
||||
|
||||
Base64 encode an /etc/default/grub with the default line set:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
echo 'GRUB_DEFAULT=0
|
||||
GRUB_HIDDEN_TIMEOUT=0
|
||||
GRUB_HIDDEN_TIMEOUT_QUIET=true
|
||||
GRUB_TIMEOUT=10
|
||||
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
|
||||
GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 modprobe.blacklist=nvidiafb,nouveau"
|
||||
GRUB_CMDLINE_LINUX=""' | base64
|
||||
|
||||
Base64 encode the following /etc/rc.local script with the correct PCI device
|
||||
IDS. In our case **0000:83:00.0** and **0000:84:00.0**.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
echo 'vfiobind() {
|
||||
dev="$1"
|
||||
vendor=$(cat /sys/bus/pci/devices/$dev/vendor)
|
||||
device=$(cat /sys/bus/pci/devices/$dev/device)
|
||||
if [ -e /sys/bus/pci/devices/$dev/driver ]; then
|
||||
echo $dev > /sys/bus/pci/devices/$dev/driver/unbind
|
||||
fi
|
||||
echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id
|
||||
}
|
||||
|
||||
vfiobind 0000:83:00.0
|
||||
vfiobind 0000:84:00.0' | base64
|
||||
|
||||
Take all the information from above to create the following YAML. Set pci_stub,
|
||||
$BASE64_ENCODED_RC_LOCAL and $BASE64_ENCODED_DEFAULT_GRUB correctly.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
cloudinit-userdata: |
|
||||
postruncmd:
|
||||
- "update-initramfs -u > /root/initramfs-update.log"
|
||||
- "update-grub > /root/grub-update.log"
|
||||
write_files:
|
||||
- path: /etc/initramfs-tools/modules
|
||||
content: pci_stub ids=10de:1bb0
|
||||
- path: /etc/modules
|
||||
content: |
|
||||
pci_stub
|
||||
vfio
|
||||
vfio_iommu_type1
|
||||
vfio_pci
|
||||
- path: /etc/rc.local
|
||||
encoding: b64
|
||||
permissions: '0755'
|
||||
content: $BASE64_ENCODED_RC_LOCAL
|
||||
- path: /etc/default/grub
|
||||
encoding: b64
|
||||
content: $BASE64_ENCODED_DEFAULT_GRUB
|
||||
|
||||
Create the juju model with cloudinit-userdata set with this YAML:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju add-model openstack-deployment --config cloudinit-userdata.yaml
|
||||
|
||||
For further cloud init documentation for customization see:
|
||||
https://cloudinit.readthedocs.io/en/latest/topics/examples.html
|
||||
|
||||
|
||||
Deploy OpenStack
|
||||
++++++++++++++++
|
||||
|
||||
At this point we are ready to deploy OpenStack using the OpenStack charms with
|
||||
Juju and MAAS. The charm deployment guide already documents this process. The
|
||||
only additional settings required are setting the PCI aliases.
|
||||
|
||||
Manually:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
juju config nova-cloud-controller pci-alias='{"vendor_id":"10de", "product_id":"1bb0", "name":"gpu"}'
|
||||
juju config nova-cloud-controller scheduler-default-filters="RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,DifferentHostFilter,SameHostFilter,AggregateInstanceExtraSpecsFilter,PciPassthroughFilter"
|
||||
juju config nova-compute pci-alias='{"vendor_id":"10de", "product_id":"1bb0", "name":"gpu"}'
|
||||
juju config nova-compute pci-passthrough-whitelist='{ "vendor_id": "10de", "product_id": "1bb0" }'
|
||||
# If passing through a GPU use spice for console which creates a usable VGA device for the VMs
|
||||
juju config nova-cloud-controller console-access-protocol=spice
|
||||
|
||||
Example bundle snippet. Update the OpenStack bundle.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
machines:
|
||||
'0':
|
||||
series: bionic
|
||||
# Use the MAAS tag pci-pass for hosts with the PCI device installed.
|
||||
constraints: tags=pci-pass
|
||||
'1':
|
||||
series: bionic
|
||||
# Use the inverse (NOT) ^pci-pass tag for hosts without the PCI device.
|
||||
constraints: tags=^pci-pass
|
||||
|
||||
applications:
|
||||
nova-compute:
|
||||
charm: cs:nova-compute
|
||||
num_units: 1
|
||||
options:
|
||||
pci-alias: '{"vendor_id":"10de", "product_id":"1bb0", "name":"gpu"}'
|
||||
pci-passthrough-whitelist: '{ "vendor_id": "10de", "product_id": "1bb0" }'
|
||||
to:
|
||||
- '0'
|
||||
nova-cloud-controller:
|
||||
charm: cs:nova-cloud-controller
|
||||
num_units: 1
|
||||
options:
|
||||
pci-alias: '{"vendor_id":"10de", "product_id":"1bb0", "name":"gpu"}'
|
||||
scheduler-default-filters="RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,DifferentHostFilter,SameHostFilter,AggregateInstanceExtraSpecsFilter,PciPassthroughFilter"
|
||||
console-access-protocol: spice
|
||||
to:
|
||||
- lxd:1
|
||||
|
||||
Post Deployment
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Create a flavor. Set the pci_passthrough property with the alias name set
|
||||
above, in our case **gpu** and the number of devices to pass in this case 1.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
openstack flavor create --ram 8192 --disk 100 --vcpu 8 m1.gpu
|
||||
openstack flavor set m1.gpu --property "pci_passthrough:alias"="gpu:1"
|
||||
|
||||
|
||||
Boot an instance with the PCI device passed through. Use the flavor just
|
||||
created:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
openstack server create --key-name $KEY --image $IMAGE --nic net-id=$NETWORK --flavor m1.gpu gpu-enabled-vm
|
||||
|
||||
SSH onto the VM and run lspci to see the PCI device in the VM. In our case the
|
||||
NVIDIA **1bb0**.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ lspci
|
||||
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
|
||||
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
|
||||
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
|
||||
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
|
||||
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
|
||||
00:02.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04)
|
||||
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
|
||||
00:04.0 Communication controller: Red Hat, Inc Virtio console
|
||||
00:05.0 SCSI storage controller: Red Hat, Inc Virtio block device
|
||||
00:06.0 VGA compatible controller: NVIDIA Corporation Device 1bb0 (rev a1)
|
||||
00:07.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon
|
||||
|
||||
Boot an instance without a PCI device passed. Use any flavor without the
|
||||
pci_passthrough property set. The PciPassthroughFilter will do the right thing.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
openstack server create --key-name $KEY --image $IMAGE --nic net-id=$NETWORK --flavor m1.medium no-gpu-vm
|
||||
|
|
@ -33,3 +33,7 @@
|
|||
/project-deploy-guide/charm-deployment-guide/latest/app-ha.html 301 /charm-guide/latest/admin/ha.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/app-trilio-vault.html 301 /charm-guide/latest/admin/trilio.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/app-masakari.html 301 /charm-guide/latest/admin/instance-ha.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/nfv.html 301 /charm-guide/latest/admin/compute/nfv.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/pci-passthrough.html 301 /charm-guide/latest/admin/compute/pci-passthrough.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/nova-cells.html 301 /charm-guide/latest/admin/compute/nova-cells.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/ironic.html 301 /charm-guide/latest/admin/compute/ironic.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue