1. To start the upgrade procedure, open the Crowbar Web interface on the Administration Server and choose Utilities+Upgrade. Alternatively, point the browser directly to the upgrade wizard on the Administration Server, for example http://192.168.124.10/upgrade/.

2. On the first screen of the Web interface you will run preliminary checks, get information about the upgrade mode and start the upgrade process.

   

3. Perform the preliminary checks to determine whether the upgrade requirements are met by clicking Check in Preliminary Checks.

   The Web interface displays the progress of the checks. You will see green, yellow or red indicator next to each check. Yellow means the upgrade can only be performed in the normal mode. Red indicates an error, which means that you need to fix the problem and run the Check again.

4. When all checks in the previous step have passed, Upgrade Mode shows the result of the upgrade analysis. It will indicate whether the upgrade procedure will continue in non-disruptive or in normal mode.

5. To start the upgrade process, click Begin Upgrade.

6. While the upgrade of the Administration Server is prepared, the upgrade wizard prompts you to Download the Backup of the Administration Server. When the backup is done, move it to a safe place. If something goes wrong during the upgrade procedure of the Administration Server, you can restore the original state from this backup using the crowbarctl backup restore NAME command.

7. Check that the repositories required for upgrading the Administration Server are available and updated. To do this, click the Check button. If the checks fail, add the software repositories as described in Chapter 5, Software Repository Setup. Run the checks again, and click Next.

   

8. Click Upgrade Administration Server to upgrade and reboot the admin node. Note that this operation may take a while. When the Administration Server has been updated, click Next.

   

9. Check that the repositories required for upgrading all nodes are available and updated. To do this click the Check button. If the check fails, add the software repositories as described in Chapter 5, Software Repository Setup. Run the checks again, and click Next.

   

10. Next, you need to stop OpenStack services. This makes the OpenStack API unavailable until the upgrade of control plane is completed. When you are ready, click Stop Services. Wait until the services are stopped and click Next.

11. Before upgrading the nodes, the wizard prompts you to Back up OpenStack Database. The MariaDB database backup will be stored on the Administration Server. It can be used to restore the database in case something goes wrong during the upgrade. To back up the database, click Create Backup. When the backup operation is finished, click Next.

12. If you prefer to upgrade the controller nodes and postpone upgrading Compute Nodes, disable the Upgrade Compute Nodes option. In this case, you can use the Go to Dashboard button to switch to the Crowbar Web interface to check the current configuration and make changes, as long as they do not affect the Compute Nodes. If you choose to postpone upgrading Compute Nodes, all OpenStack services remain up and running.

    

13. When the upgrade is completed, press Finish to return to the Dashboard.

    

1. To start the upgrade procedure from the command line, log in to the Administration Server as root.

2. Perform the preliminary checks to determine whether the upgrade requirements are met:

   root # crowbarctl upgrade prechecks

   The command's result is shown in a table. Make sure the column Errors does not contain any entries. If there are errors, fix them and restart the precheck command afterwards. You cannot proceed until the mandatory checks have passed.

   root # crowbarctl upgrade prechecks
               +-------------------------------+--------+----------+--------+------+
               | Check ID                      | Passed | Required | Errors | Help |
               +-------------------------------+--------+----------+--------+------+
               | network_checks                | true   | true     |        |      |
               | cloud_healthy                 | true   | true     |        |      |
               | maintenance_updates_installed | true   | true     |        |      |
               | compute_status                | true   | false    |        |      |
               | ha_configured                 | true   | false    |        |      |
               | clusters_healthy              | true   | true     |        |      |
               +-------------------------------+--------+----------+--------+------+

   Depending on the outcome of the checks, it is automatically decided whether the upgrade procedure will continue in non-disruptive or in normal mode. For the non-disruptive mode, all the checks must pass, including those that are not marked in the table as required.

   Forcing Normal Mode Upgrade

   The non-disruptive update will take longer than an upgrade in normal mode, because it performs certain tasks sequentially which are done in parallel during the normal upgrade. Live-migrating guests to other Compute Nodes during the non-disruptive upgrade takes additional time.

   Therefore, if a non-disruptive upgrade is not a requirement for you, you may want to switch to the normal upgrade mode, even if your setup supports the non-disruptive method. To force the normal upgrade mode, run:

   root # crowbarctl upgrade mode normal

   To query the current upgrade mode run:

   root # crowbarctl upgrade mode

   To switch back to the non-disruptive mode run:

   root # crowbarctl upgrade mode non_disruptive

   It is possible to call this command at any time during the upgrade process until the services step is started. After that point the upgrade mode can no longer be changed.

3. Prepare the nodes by transitioning them into the “upgrade” state and stopping the chef daemon:

   root # crowbarctl upgrade prepare

   Depending of the size of your SUSE OpenStack Cloud deployment, this step may take some time. Use the command crowbarctl upgrade status to monitor the status of the process named steps.prepare.status. It needs to be in state passed before you proceed:

   root # crowbarctl upgrade status
               +--------------------------------+----------------+
               | Status                         | Value          |
               +--------------------------------+----------------+
               | current_step                   | backup_crowbar |
               | current_substep                |                |
               | current_substep_status         |                |
               | current_nodes                  |                |
               | current_node_action            |                |
               | remaining_nodes                |                |
               | upgraded_nodes                 |                |
               | crowbar_backup                 |                |
               | openstack_backup               |                |
               | suggested_upgrade_mode         | non_disruptive |
               | selected_upgrade_mode          |                |
               | compute_nodes_postponed        | false          |
               | steps.prechecks.status         | passed         |
               | steps.prepare.status           | passed         |
               | steps.backup_crowbar.status    | pending        |
               | steps.repocheck_crowbar.status | pending        |
               | steps.admin.status             | pending        |
               | steps.repocheck_nodes.status   | pending        |
               | steps.services.status          | pending        |
               | steps.backup_openstack.status  | pending        |
               | steps.nodes.status             | pending        |
               +--------------------------------+----------------+

4. Create a backup of the existing Administration Server installation. In case something goes wrong during the upgrade procedure of the Administration Server you can restore the original state from this backup with the command crowbarctl backup restore NAME

   root # crowbarctl upgrade backup crowbar

   To list all existing backups including the one you have just created, run the following command:

   root # crowbarctl backup list
               +----------------------------+--------------------------+--------+---------+
               | Name                       | Created                  | Size   | Version |
               +----------------------------+--------------------------+--------+---------+
               | crowbar_upgrade_1534864741 | 2018-08-21T15:19:03.138Z | 219 KB | 4.0     |
               +----------------------------+--------------------------+--------+---------+

5. This step prepares the upgrade of the Administration Server by checking the availability of the update and pool repositories for SUSE OpenStack Cloud Crowbar 9 and SUSE Linux Enterprise Server 12 SP4. Run the following command:

   root # crowbarctl upgrade repocheck crowbar
               +----------------------------------------+------------------+-----------+
               | Repository                             | Status           | Type      |
               +----------------------------------------+------------------+-----------+
               | SLES12-SP4-Pool                        | x86_64 (missing) | os        |
               | SLES12-SP4-Updates                     | x86_64 (missing) | os        |
               | SUSE-OpenStack-Cloud-Crowbar-9-Pool    | available        | openstack |
               | SUSE-OpenStack-Cloud-Crowbar-9-Updates | available        | openstack |
               +----------------------------------------+------------------+-----------+

   Two of the required repositories are reported as missing, because they have not yet been added to the Crowbar configuration. To add them to the Administration Server proceed as follows.

   Note that this step is for setting up the repositories for the Administration Server, not for the nodes in SUSE OpenStack Cloud (this will be done in a subsequent step).

   1. Start yast repositories and proceed with Continue. Replace the repositories SLES12-SP3-Pool and SLES12-SP3-Updates with the respective SP4 repositories.

      If you prefer to use zypper over YaST, you may alternatively make the change using zypper mr.

   2. Next, replace the SUSE-OpenStack-Cloud-Crowbar-8 update and pool repositories with the respective SUSE OpenStack Cloud Crowbar 9 versions.

   3. Check for other (custom) repositories. All SLES SP3 repositories need to be replaced with the respective SLES SP4 version. In case no SP3 version exists, disable the repository—the respective packages from that repository will be deleted during the upgrade.

   Administration Server with external SMT

   If the Administration Server is configured with external SMT, the system repositories configuration is managed by the system utilities. In this case, skip the above substeps and run the zypper migration --download-only command.

   Once the repository configuration on the Administration Server has been updated, run the command to check the repositories again. If the configuration is correct, the result should look like the following:

   root # crowbarctl upgrade repocheck crowbar
               +----------------------------------------+-----------+-----------+
               | Repository                             | Status    | Type      |
               +----------------------------------------+-----------+-----------+
               | SLES12-SP4-Pool                        | available | os        |
               | SLES12-SP4-Updates                     | available | os        |
               | SUSE-OpenStack-Cloud-Crowbar-9-Pool    | available | openstack |
               | SUSE-OpenStack-Cloud-Crowbar-9-Updates | available | openstack |
               +----------------------------------------+-----------+-----------+

6. Now that the repositories are available, the Administration Server itself will be upgraded. The update will run in the background using zypper dup. Once all packages have been upgraded, the Administration Server will be rebooted and you will be logged out. To start the upgrade run:

   root # crowbarctl upgrade admin

7. After the Administration Server has been successfully updated, the Control Nodes and Compute Nodes will be upgraded. At first the availability of the repositories used to provide packages for the SUSE OpenStack Cloud nodes is tested.

   Correct Metadata in the PTF Repository

   When adding new repositories to the nodes, make sure that the new PTF repository also contains correct metadata (even if it is empty). To do this, run the createrepo-cloud-ptf command.

   Note that the configuration for these repositories differs from the one for the Administration Server that was already done in a previous step. In this step the repository locations are made available to Crowbar rather than to libzypp on the Administration Server. To check the repository configuration run the following command:

   root # crowbarctl upgrade repocheck nodes
               +----------------------------------------+-------------------------------------+-----------+
               | Repository                             | Status                              | Type      |
               +----------------------------------------+-------------------------------------+-----------+
               | SLE12-SP4-HA-Pool                      | missing (x86_64), inactive (x86_64) | ha        |
               | SLE12-SP4-HA-Updates                   | missing (x86_64), inactive (x86_64) | ha        |
               | SLE12-SP4-HA-Updates-test              | missing (x86_64), inactive (x86_64) | ha        |
               | SLES12-SP4-Pool                        | missing (x86_64), inactive (x86_64) | os        |
               | SLES12-SP4-Updates                     | missing (x86_64), inactive (x86_64) | os        |
               | SLES12-SP4-Updates-test                | missing (x86_64), inactive (x86_64) | os        |
               | SUSE-OpenStack-Cloud-Crowbar-9-Pool    | missing (x86_64), inactive (x86_64) | openstack |
               | SUSE-OpenStack-Cloud-Crowbar-9-Updates | missing (x86_64), inactive (x86_64) | openstack |
               +----------------------------------------+-------------------------------------+-----------+

   To update the locations for the listed repositories, start yast crowbar and proceed as described in the section called “Repositories”.

   Once the repository configuration for Crowbar has been updated, run the command to check the repositories again to determine, whether the current configuration is correct.

   root # crowbarctl upgrade repocheck nodes
               +----------------------------------------+-----------+-----------+
               | Repository                             | Status    | Type      |
               +----------------------------------------+-----------+-----------+
               | SLE12-SP4-HA-Pool                      | available | ha        |
               | SLE12-SP4-HA-Updates                   | available | ha        |
               | SLES12-SP4-Pool                        | available | os        |
               | SLES12-SP4-Updates                     | available | os        |
               | SUSE-OpenStack-Cloud-Crowbar-9-Pool    | available | openstack |
               | SUSE-OpenStack-Cloud-Crowbar-9-Updates | available | openstack |
               +----------------------------------------+-----------+-----------+

   Shut Down Running instances in Normal Mode

   If the upgrade is done in the normal mode, you need to shut down or suspend all running instances before performing the next step.

   Product Media Repository Copies

   To PXE boot new nodes, an additional SUSE Linux Enterprise Server 12 SP4 repository—a copy of the installation system— is required. Although not required during the upgrade procedure, it is recommended to set up this directory now. Refer to the section called “Copying the Product Media Repositories” for details. If you had also copied the SUSE OpenStack Cloud Crowbar 8 installation media (optional), you may also want to provide the SUSE OpenStack Cloud Crowbar 9 the same way.

   Once the upgrade procedure has been successfully finished, you may delete the previous copies of the installation media in /srv/tftpboot/suse-12.4/x86_64/install and /srv/tftpboot/suse-12.4/x86_64/repos/Cloud.

8. To ensure the status of the nodes does not change during the upgrade process, the majority of the OpenStack services will be stopped on the nodes. As a result, the OpenStack API will no longer be accessible. In case of the non-disruptive mode, the instances will continue to run and stay accessible. Run the following command:

   root # crowbarctl upgrade services

   This step takes a while to finish. Monitor the process by running crowbarctl upgrade status. Do not proceed before steps.services.status is set to passed.

9. The last step before upgrading the nodes is to make a backup of the OpenStack database. The database dump will be stored on the Administration Server and can be used to restore the database in case something goes wrong during the upgrade.

   root # crowbarctl upgrade backup openstack

   To find the location of the database dump, run the crowbarctl upgrade status.

10. The final step of the upgrade procedure is upgrading the nodes. To start the process, enter:

    root # crowbarctl upgrade nodes all

    The upgrade process runs in the background and can be queried with crowbarctl upgrade status. Depending on the size of your SUSE OpenStack Cloud it may take several hours, especially when performing a non-disruptive update. In that case, the Compute Nodes are updated one-by-one after instances have been live-migrated to other nodes.

    Instead of upgrading all nodes you may also upgrade the Control Nodes first and individual Compute Nodes afterwards. Refer to crowbarctl upgrade nodes --help for details. If you choose this approach, you can use the crowbarctl upgrade status command to monitor the upgrade process. The output of this command contains the following entries:

    current_node_action

    The current action applied to the node.

    current_substep

    Shows the current substep of the node upgrade step. For example, for the crowbarctl upgrade nodes controllers, the current_substep entry displays the controller_nodes status when upgrading controllers.

    After the controllers have been upgraded, the steps.nodes.status entry in the output displays the running status. Check then the status of the current_substep_status entry. If it displays finished, you can move to the next step of upgrading the Compute Nodes.

    Postponing the Upgrade

    It is possible to stop the upgrade of compute nodes and postpone their upgrade with the command:

    root # crowbarctl upgrade nodes postpone

    After the upgrade of compute nodes is postponed, you can go to Crowbar Web interface, check the configuration. You can also apply some changes, provided they do not affect the Compute Nodes. During the postponed upgrade, all OpenStack services should be up and running.

    To resume the upgrade, issue the command:

    root # crowbarctl upgrade nodes resume

    Finish the upgrade with either crowbarctl upgrade nodes all or upgrade nodes one node by one with crowbarctl upgrade nodes NODE_NAME.

    When upgrading individual Compute Nodes using the crowbarctl upgrade nodes NODE_NAME command, the current_substep_status entry changes to node_finished when the upgrade of a single node is done. After all nodes have been upgraded, the current_substep_status entry displays finished.

Procedure 1.2.  Manually deleting load balancers created with neutron lbaasv2 (in an upgrade/migration scenario)

1. Query the Neutron service for the loadbalancer ID:

   tux > neutron lbaas-loadbalancer-list
   neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
   +--------------------------------------+---------+----------------------------------+--------------+---------------------+----------+
   | id                                   | name    | tenant_id                        | vip_address  | provisioning_status | provider |
   +--------------------------------------+---------+----------------------------------+--------------+---------------------+----------+
   | 7be4e4ab-e9c6-4a57-b767-da9af5ba7405 | test-lb | d62a1510b0f54b5693566fb8afeb5e33 | 192.168.1.10 | ERROR               | haproxy  |
   +--------------------------------------+---------+----------------------------------+--------------+---------------------+----------+
           

2. Connect to the neutron database:

   Important

   The default database name depends on the life cycle manager. Ardana uses ovs_neutron while Crowbar uses neutron.

   Ardana:

   mysql> use ovs_neutron
           

   Crowbar:

   mysql> use neutron
           

3. Get the pools and healthmonitors associated with the loadbalancer:

   mysql> select id, healthmonitor_id, loadbalancer_id from lbaas_pools where loadbalancer_id = '7be4e4ab-e9c6-4a57-b767-da9af5ba7405';
   +--------------------------------------+--------------------------------------+--------------------------------------+
   | id                                   | healthmonitor_id                     | loadbalancer_id                      |
   +--------------------------------------+--------------------------------------+--------------------------------------+
   | 26c0384b-fc76-4943-83e5-9de40dd1c78c | 323a3c4b-8083-41e1-b1d9-04e1fef1a331 | 7be4e4ab-e9c6-4a57-b767-da9af5ba7405 |
   +--------------------------------------+--------------------------------------+--------------------------------------+
           

4. Get the members associated with the pool:

   mysql> select id, pool_id from lbaas_members where pool_id = '26c0384b-fc76-4943-83e5-9de40dd1c78c';
   +--------------------------------------+--------------------------------------+
   | id                                   | pool_id                              |
   +--------------------------------------+--------------------------------------+
   | 6730f6c1-634c-4371-9df5-1a880662acc9 | 26c0384b-fc76-4943-83e5-9de40dd1c78c |
   | 06f0cfc9-379a-4e3d-ab31-cdba1580afc2 | 26c0384b-fc76-4943-83e5-9de40dd1c78c |
   +--------------------------------------+--------------------------------------+
           

5. Delete the pool members:

   mysql> delete from lbaas_members where id = '6730f6c1-634c-4371-9df5-1a880662acc9';
   mysql> delete from lbaas_members where id = '06f0cfc9-379a-4e3d-ab31-cdba1580afc2';
           

6. Find and delete the listener associated with the loadbalancer:

   mysql> select id, loadbalancer_id, default_pool_id from lbaas_listeners where loadbalancer_id = '7be4e4ab-e9c6-4a57-b767-da9af5ba7405';
   +--------------------------------------+--------------------------------------+--------------------------------------+
   | id                                   | loadbalancer_id                      | default_pool_id                      |
   +--------------------------------------+--------------------------------------+--------------------------------------+
   | 3283f589-8464-43b3-96e0-399377642e0a | 7be4e4ab-e9c6-4a57-b767-da9af5ba7405 | 26c0384b-fc76-4943-83e5-9de40dd1c78c |
   +--------------------------------------+--------------------------------------+--------------------------------------+
   mysql> delete from lbaas_listeners where id = '3283f589-8464-43b3-96e0-399377642e0a';
           

7. Delete the pool associated with the loadbalancer:

   mysql> delete from lbaas_pools where id = '26c0384b-fc76-4943-83e5-9de40dd1c78c';
           

8. Delete the healthmonitor associated with the pool:

   mysql> delete from lbaas_healthmonitors where id = '323a3c4b-8083-41e1-b1d9-04e1fef1a331';
           

9. Delete the loadbalancer:

   mysql> delete from lbaas_loadbalancer_statistics where loadbalancer_id = '7be4e4ab-e9c6-4a57-b767-da9af5ba7405';
   mysql> delete from lbaas_loadbalancers where id = '7be4e4ab-e9c6-4a57-b767-da9af5ba7405';
           

Procedure 1.3. Manually Deleting Load Balancers Created With Octavia

1. Query the Octavia service for the loadbalancer ID:

   tux > openstack loadbalancer list --column id --column name --column provisioning_status
   +--------------------------------------+---------+---------------------+
   | id                                   | name    | provisioning_status |
   +--------------------------------------+---------+---------------------+
   | d8ac085d-e077-4af2-b47a-bdec0c162928 | test-lb | ERROR               |
   +--------------------------------------+---------+---------------------+
           

2. Query the Octavia service for the amphora IDs (in this example we use ACTIVE/STANDBY topology with 1 spare Amphora):

   tux > openstack loadbalancer amphora list
   +--------------------------------------+--------------------------------------+-----------+--------+---------------+-------------+
   | id                                   | loadbalancer_id                      | status    | role   | lb_network_ip | ha_ip       |
   +--------------------------------------+--------------------------------------+-----------+--------+---------------+-------------+
   | 6dc66d41-e4b6-4c33-945d-563f8b26e675 | d8ac085d-e077-4af2-b47a-bdec0c162928 | ALLOCATED | BACKUP | 172.30.1.7    | 192.168.1.8 |
   | 1b195602-3b14-4352-b355-5c4a70e200cf | d8ac085d-e077-4af2-b47a-bdec0c162928 | ALLOCATED | MASTER | 172.30.1.6    | 192.168.1.8 |
   | b2ee14df-8ac6-4bb0-a8d3-3f378dbc2509 | None                                 | READY     | None   | 172.30.1.20   | None        |
   +--------------------------------------+--------------------------------------+-----------+--------+---------------+-------------+
           

3. Query the Octavia service for the loadbalancer pools:

   tux > openstack loadbalancer pool list
   +--------------------------------------+-----------+----------------------------------+---------------------+----------+--------------+----------------+
   | id                                   | name      | project_id                       | provisioning_status | protocol | lb_algorithm | admin_state_up |
   +--------------------------------------+-----------+----------------------------------+---------------------+----------+--------------+----------------+
   | 39c4c791-6e66-4dd5-9b80-14ea11152bb5 | test-pool | 86fba765e67f430b83437f2f25225b65 | ACTIVE              | TCP      | ROUND_ROBIN  | True           |
   +--------------------------------------+-----------+----------------------------------+---------------------+----------+--------------+----------------+
           

4. Connect to the octavia database:

   mysql> use octavia
           

5. Delete any listeners, pools, health monitors, and members from the load balancer:

   mysql> delete from listener where load_balancer_id = 'd8ac085d-e077-4af2-b47a-bdec0c162928';
   mysql> delete from health_monitor where pool_id = '39c4c791-6e66-4dd5-9b80-14ea11152bb5';
   mysql> delete from member where pool_id = '39c4c791-6e66-4dd5-9b80-14ea11152bb5';
   mysql> delete from pool where load_balancer_id = 'd8ac085d-e077-4af2-b47a-bdec0c162928';
           

6. Delete the amphora entries in the database:

   mysql> delete from amphora_health where amphora_id = '6dc66d41-e4b6-4c33-945d-563f8b26e675';
   mysql> update amphora set status = 'DELETED' where id = '6dc66d41-e4b6-4c33-945d-563f8b26e675';
   mysql> delete from amphora_health where amphora_id = '1b195602-3b14-4352-b355-5c4a70e200cf';
   mysql> update amphora set status = 'DELETED' where id = '1b195602-3b14-4352-b355-5c4a70e200cf';
           

7. Delete the load balancer instance:

   mysql> update load_balancer set provisioning_status = 'DELETED' where id = 'd8ac085d-e077-4af2-b47a-bdec0c162928';
           

8. The following script automates the above steps:

   #!/bin/bash
   
   if (( $# != 1 )); then
   echo "Please specify a loadbalancer ID"
   exit 1
   fi
   
   LB_ID=$1
   
   set -u -e -x
   
   readarray -t AMPHORAE < <(openstack loadbalancer amphora list \
   --format value \
   --column id \
   --column loadbalancer_id \
   | grep ${LB_ID} \
   | cut -d ' ' -f 1)
   
   readarray -t POOLS < <(openstack loadbalancer show ${LB_ID} \
   --format value \
   --column pools)
   
   mysql octavia --execute "delete from listener where load_balancer_id = '${LB_ID}';"
   for p in "${POOLS[@]}"; do
   mysql octavia --execute "delete from health_monitor where pool_id = '${p}';"
   mysql octavia --execute "delete from member where pool_id = '${p}';"
   done
   mysql octavia --execute "delete from pool where load_balancer_id = '${LB_ID}';"
   for a in "${AMPHORAE[@]}"; do
   mysql octavia --execute "delete from amphora_health where amphora_id = '${a}';"
   mysql octavia --execute "update amphora set status = 'DELETED' where id = '${a}';"
   done
   mysql octavia --execute "update load_balancer set provisioning_status = 'DELETED' where id = '${LB_ID}';"
           

Procedure 2.2. Configure the Compute Host

1. Login to the compute host and change directory to /etc/nova/nova.conf.d and list all the files:

   root # cd /etc/nova/nova.conf.d/
   ls -al
   

2. Create a new nova configuration file under this folder and name the file appropriately. Note that configuration files are read and applied in lexicographic order. For example: 102-nova-pcipassthru.conf .

3. Add the following configuration entries to the file and the values for these entries are specific to your compute node as obtained in Preparing the Compute Node step Procedure 2.1, “Preparing the Compute Node”. The configuration entries specify the PCI device using whitelisting and the PCI alias for the device. Example:

   root # cat /etc/nova/nova.conf.d/102-nova-pcipassthru.conf
   [pci]
   passthrough_whitelist = [{ "address": "0000:84:00.0" }]
   alias = { "vendor_id":"10de", "product_id":"1db4", "device_type":"type-PCI", "name":"a1" }
   
   

   The example above shows how to configure a PCI alias a1 to request a PCI device with a vendor_id of 10de and a product_id of 1db4.

4. Once the file is updated, restart nova compute on the compute node:

   root # systemctl restart openstack-nova-compute
       

Procedure 2.3. Configure the Controller nodes

1. Follow the following steps for all the controller nodes. Login to the controller host and change directory to /etc/nova/nova.conf.d and list all the files under that folder:

   root # cd /etc/nova/nova.conf.d/
   ls -al
   

2. Create a new nova configuration file under this folder and name the file appropriately in lexicographic increasing order. For example: 102-nova-pcipassthru.conf .

3. Add the following configuration entries to the file and the configuration entries for controller nodes only specify PCI alias for the device from the compute host. For example:

   root # cat /etc/nova/nova.conf.d/102-nova-pcipassthru.conf
   [pci]
   alias = { "vendor_id":"10de", "product_id":"1db4", "device_type":"type-PCI", "name":"a1" }
   

   The example above shows how to configure a PCI alias a1 to request a PCI device with a vendor_id of 10de and a product_id of 1db4.

4. Once the file is updated, restart nova api on the controller node:

   root # systemctl restart openstack-nova-api