stackhpc · jovial · Nov 20, 2019 · Jul 30, 2020 · May 1, 2020 · Sep 3, 2020
diff --git a/.zuul.yaml b/.zuul.yaml
@@ -118,6 +118,17 @@
       python_version: 3.7
     timeout: 3600
 
+- job:
+    name: nova-tox-validate-backport
+    parent: openstack-tox
+    description: |
+      Determine whether a backport is ready to be merged by checking whether it
+      has already been merged to master or more recent stable branches.
+
+      Uses tox with the ``validate-backport`` environment.
+    vars:
+      tox_envlist: validate-backport
+
 - job:
     name: nova-live-migration
     parent: nova-dsvm-multinode-base
@@ -393,6 +404,8 @@
         - nova-next
         - nova-tox-functional
         - nova-tox-functional-py36
+        - nova-tox-validate-backport:
+            voting: false
         - tempest-integrated-compute:
             irrelevant-files: *dsvm-irrelevant-files
         - tempest-slow-py3:
@@ -409,6 +422,7 @@
         - nova-tox-functional-py36
         - nova-multi-cell
         - nova-next
+        - nova-tox-validate-backport
         - tempest-integrated-compute:
             irrelevant-files: *dsvm-irrelevant-files
         - tempest-slow-py3:

diff --git a/api-ref/source/parameters.yaml b/api-ref/source/parameters.yaml
@@ -2449,9 +2449,10 @@ disk_available_least_total:
 disk_bus:
   description: |
     Disk bus type, some hypervisors (currently only libvirt) support
-    specify this parameter. Some example disk_bus values can be: `ide`,
-    `usb`, `virtio`, `scsi`. This is not an exhaustive list as it depends
-    on the virtualization driver, and may change as more support is added.
+    specify this parameter. Some example disk_bus values can be: ``fdc``,
+    ``ide``, ``sata``, ``scsi``, ``usb``, ``virtio``, ``xen``, ``lxc``
+    and ``uml``. Support for each bus type depends on the virtualization driver
+    and underlying hypervisor.
   in: body
   required: false
   type: string

diff --git a/doc/source/admin/pci-passthrough.rst b/doc/source/admin/pci-passthrough.rst
@@ -15,156 +15,188 @@ 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.
 
+PCI devices are requested through flavor extra specs, specifically via the
+``pci_passthrough:alias=<alias>`` flavor extra spec.  This guide demonstrates
+how to enable PCI passthrough for a type of PCI device with a vendor ID of
+``8086`` and a product ID of ``154d`` - an Intel X520 Network Adapter - by
+mapping them to the alias ``a1``. You should adjust the instructions for other
+devices with potentially different capabilities.
+
 .. note::
 
-   For information on creating servers with virtual SR-IOV devices, refer to
+   For information on creating servers with SR-IOV network interfaces, refer to
    the :neutron-doc:`Networking Guide <admin/config-sriov>`.
 
    **Limitations**
 
-   * Attaching SR-IOV ports to existing servers is not currently supported, see
-     `bug 1708433 <https://bugs.launchpad.net/nova/+bug/1708433>`_ for details.
+   * Attaching SR-IOV ports to existing servers is not currently supported.
+     This is now rejected by the API but previously it fail later in the
+     process. See `bug 1708433 <https://bugs.launchpad.net/nova/+bug/1708433>`_
+     for details.
    * Cold migration (resize) of servers with SR-IOV devices attached was not
      supported until the 14.0.0 Newton release, see
      `bug 1512800 <https://bugs.launchpad.net/nova/+bug/1512880>`_ for details.
 
-To enable PCI passthrough, follow the steps below:
 
-#. Configure nova-scheduler (Controller)
+Configure host (Compute)
+------------------------
 
-#. Configure nova-api (Controller)**
+To enable PCI passthrough on an x86, Linux-based compute node, the following
+are required:
 
-#. Configure a flavor (Controller)
+* VT-d enabled in the BIOS
+* IOMMU enabled on the host OS, e.g. by adding the ``intel_iommu=on`` or
+  ``amd_iommu=on`` parameter to the kernel parameters
+* Assignable PCIe devices
 
-#. Enable PCI passthrough (Compute)
+To enable PCI passthrough on a Hyper-V compute node, the following are
+required:
 
-#. Configure PCI devices in nova-compute (Compute)
+* Windows 10 or Windows / Hyper-V Server 2016 or newer
+* VT-d enabled on the host
+* Assignable PCI devices
 
-.. note::
+In order to check the requirements above and if there are any assignable PCI
+devices, run the following Powershell commands:
 
-   The PCI device with address ``0000:41:00.0`` is used as an example. This
-   will differ between environments.
+.. code-block:: console
 
-Configure nova-scheduler (Controller)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    Start-BitsTransfer https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-samples/benarm-powershell/DDA/survey-dda.ps1
+     .\survey-dda.ps1
 
-#. Configure ``nova-scheduler`` as specified in :neutron-doc:`Configure
-   nova-scheduler
-   <admin/config-sriov.html#configure-nova-scheduler-controller>`.
+If the compute node passes all the requirements, the desired assignable PCI
+devices to be disabled and unmounted from the host, in order to be assignable
+by Hyper-V. The following can be read for more details: `Hyper-V PCI
+passthrough`__.
 
-#. Restart the ``nova-scheduler`` service.
+.. __: https://devblogs.microsoft.com/scripting/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/
 
-Configure nova-api (Controller)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-#. Specify the PCI alias for the device.
+Configure ``nova-compute`` (Compute)
+------------------------------------
 
-   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``.
+Once PCI passthrough has been configured for the host, :program:`nova-compute`
+must be configured to allow the PCI device to pass through to VMs. This is done
+using the :oslo.config:option:`pci.passthrough_whitelist` option. For example,
+assuming our sample PCI device has a PCI address of ``41:00.0`` on each host:
 
-   Edit ``/etc/nova/nova.conf``:
+.. code-block:: ini
 
-   .. code-block:: ini
+   [pci]
+   passthrough_whitelist = { "address": "0000:41:00.0" }
 
-      [pci]
-      alias = { "vendor_id":"8086", "product_id":"154d", "device_type":"type-PF", "name":"a1" }
+Refer to :oslo.config:option:`pci.passthrough_whitelist` for syntax information.
 
-   Refer to :oslo.config:option:`pci.alias` for syntax information.
+Alternatively, to enable passthrough of all devices with the same product and
+vendor ID:
 
-#. Restart the ``nova-api`` service.
+.. code-block:: ini
 
-Configure a flavor (Controller)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   [pci]
+   passthrough_whitelist = { "vendor_id": "8086", "product_id": "154d" }
 
-Configure a flavor to request two PCI devices, each with ``vendor_id`` of
-``0x8086`` and ``product_id`` of ``0x154d``:
+If using vendor and product IDs, all PCI devices matching the ``vendor_id`` and
+``product_id`` are added to the pool of PCI devices available for passthrough
+to VMs.
 
-.. code-block:: console
+In addition, it is necessary to configure the :oslo.config:option:`pci.alias`
+option, which is a JSON-style configuration option that allows you to map a
+given device type, identified by the standard PCI ``vendor_id`` and (optional)
+``product_id`` fields, to an arbitrary name or *alias*. This alias can then be
+used to request a PCI device using the ``pci_passthrough:alias=<alias>`` flavor
+extra spec, as discussed previously. For our sample device with a vendor ID of
+``0x8086`` and a product ID of ``0x154d``, this would be:
 
-   # openstack flavor set m1.large --property "pci_passthrough:alias"="a1:2"
+.. code-block:: ini
 
-For more information about the syntax for ``pci_passthrough:alias``, refer to
-:ref:`Flavors <extra-spec-pci-passthrough>`.
+   [pci]
+   alias = { "vendor_id":"8086", "product_id":"154d", "device_type":"type-PF", "name":"a1" }
 
-Enable PCI passthrough (Compute)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+It's important to note the addition of the ``device_type`` field. This is
+necessary because this PCI device supports SR-IOV. The ``nova-compute`` service
+categorizes devices into one of three types, depending on the capabilities the
+devices report:
 
-Enable VT-d and IOMMU. For more information, refer to steps one and two in
-:neutron-doc:`Create Virtual Functions
-<admin/config-sriov.html#create-virtual-functions-compute>`.
+``type-PF``
+  The device supports SR-IOV and is the parent or root device.
 
-For Hyper-V compute nodes, the requirements are as follows:
+``type-VF``
+  The device is a child device of a device that supports SR-IOV.
 
-* Windows 10 or Windows / Hyper-V Server 2016 or newer.
-* VT-d and SR-IOV enabled on the host.
-* Assignable PCI devices.
+``type-PCI``
+  The device does not support SR-IOV.
 
-In order to check the requirements above and if there are any assignable PCI
-devices, run the following Powershell commands:
+By default, it is only possible to attach ``type-PCI`` devices using PCI
+passthrough. If you wish to attach ``type-PF`` or ``type-VF`` devices, you must
+specify the ``device_type`` field in the config option. If the device was a
+device that did not support SR-IOV, the ``device_type`` field could be omitted.
 
-.. code-block:: console
+Refer to :oslo.config:option:`pci.alias` for syntax information.
 
-    Start-BitsTransfer https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-samples/benarm-powershell/DDA/survey-dda.ps1
-     .\survey-dda.ps1
+.. important::
 
-If the compute node passes all the requirements, the desired assignable PCI
-devices to be disabled and unmounted from the host, in order to be assignable
-by Hyper-V. The following can be read for more details: `Hyper-V PCI
-passthrough`__.
+   This option must also be configured on controller nodes. This is discussed later
+   in this document.
 
-.. __: https://devblogs.microsoft.com/scripting/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/
+Once configured, restart the :program:`nova-compute` service.
+
+
+Configure ``nova-scheduler`` (Controller)
+-----------------------------------------
+
+The :program:`nova-scheduler` service must be configured to enable the
+``PciPassthroughFilter``. To do this, add this filter to the list of filters
+specified in :oslo.config:option:`filter_scheduler.enabled_filters` and set
+:oslo.config:option:`filter_scheduler.available_filters` to the default of
+``nova.scheduler.filters.all_filters``. For example:
 
-Configure PCI devices (Compute)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. code-block:: ini
 
-#. Configure ``nova-compute`` to allow the PCI device to pass through to
-   VMs. Edit ``/etc/nova/nova.conf``:
+   [filter_scheduler]
+   enabled_filters = ...,PciPassthroughFilter
+   available_filters = nova.scheduler.filters.all_filters
 
-   .. code-block:: ini
+Once done, restart the :program:`nova-scheduler` service.
 
-      [pci]
-      passthrough_whitelist = { "address": "0000:41:00.0" }
 
-   Alternatively specify multiple PCI devices using whitelisting:
+.. _pci-passthrough-alias:
 
-   .. code-block:: ini
+Configure ``nova-api`` (Controller)
+-----------------------------------
 
-      [pci]
-      passthrough_whitelist = { "vendor_id": "8086", "product_id": "10fb" }
+It is necessary to also configure the :oslo.config:option:`pci.alias` config
+option on the controller. This configuration should match the configuration
+found on the compute nodes. For example:
 
-   All PCI devices matching the ``vendor_id`` and ``product_id`` are added to
-   the pool of PCI devices available for passthrough to VMs.
+.. code-block:: ini
 
-   Refer to :oslo.config:option:`pci.passthrough_whitelist` for syntax
-   information.
+   [pci]
+   alias = { "vendor_id":"8086", "product_id":"154d", "device_type":"type-PF", "name":"a1" }
 
-#. Specify the PCI alias for the device.
+Refer to :oslo.config:option:`pci.alias` for syntax information.
 
-   From the Newton release, to resize guest with PCI device, configure the PCI
-   alias on the compute node as well.
+Once configured, restart the :program:`nova-api` service.
 
-   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``:
+Configure a flavor (API)
+------------------------
 
-   .. code-block:: ini
+Once the alias has been configured, it can be used for an flavor extra spec.
+For example, to request two of the PCI devices referenced by alias ``a1``, run:
 
-      [pci]
-      alias = { "vendor_id":"8086", "product_id":"154d", "device_type":"type-PF", "name":"a1" }
+.. code-block:: console
+
+   $ openstack flavor set m1.large --property "pci_passthrough:alias"="a1:2"
 
-   Refer to :oslo.config:option:`pci.alias` for syntax information.
+For more information about the syntax for ``pci_passthrough:alias``, refer to
+:ref:`Flavors <extra-spec-pci-passthrough>`.
 
-#. 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
-``alias`` from the flavor.
+The :program:`nova-scheduler` service selects a destination host that has PCI
+devices available that match the ``alias`` specified in the flavor.
 
 .. code-block:: console
 

diff --git a/doc/source/admin/secure-live-migration-with-qemu-native-tls.rst b/doc/source/admin/secure-live-migration-with-qemu-native-tls.rst
@@ -120,17 +120,26 @@ Performing the migration
 
 (1) On all relevant compute nodes, enable the
     :oslo.config:option:`libvirt.live_migration_with_native_tls`
-    configuration attribute::
+    configuration attribute and set the
+    :oslo.config:option:`libvirt.live_migration_scheme`
+    configuration attribute to tls::
 
        [libvirt]
        live_migration_with_native_tls = true
+       live_migration_scheme = tls
 
     .. note::
         Setting both
         :oslo.config:option:`libvirt.live_migration_with_native_tls` and
         :oslo.config:option:`libvirt.live_migration_tunnelled` at the
         same time is invalid (and disallowed).
 
+    .. note::
+        Not setting
+        :oslo.config:option:`libvirt.live_migration_scheme` to ``tls``
+        will result in libvirt using the unencrypted TCP connection
+        without displaying any error or a warning in the logs.
+
     And restart the ``nova-compute`` service::
 
         $ systemctl restart openstack-nova-compute

diff --git a/doc/source/admin/virtual-persistent-memory.rst b/doc/source/admin/virtual-persistent-memory.rst
@@ -31,12 +31,23 @@ The following are required to support the vPMEM feature:
 
   ``dax_pmem``, ``nd_pmem``, ``device_dax``, ``nd_btt``
 
+.. note::
+
+  NVDIMM support is present in the Linux Kernel v4.0 or newer. It is
+  recommended to use Kernel version 4.2 or later since `NVDIMM support
+  <https://docs.pmem.io/persistent-memory/getting-started-guide/creating-development-environments/linux-environments>`_
+  is enabled by default. We met some bugs in older versions, and we have
+  done all verification works with OpenStack on 4.18 version, so 4.18
+  version and newer will probably guarantee its functionality.
+
 * QEMU version >= 3.1.0
 
 * Libvirt version >= 5.0.0
 
 * `ndctl`_ version >= 62
 
+* daxio version >= 1.6
+
 The vPMEM feature has been verified under the software and hardware listed above.
 
 

diff --git a/doc/source/user/flavors.rst b/doc/source/user/flavors.rst
@@ -706,10 +706,14 @@ Hiding hypervisor signature
      As of the 18.0.0 Rocky release, this is only supported by the libvirt
      driver.
 
+     Prior to the 21.0.0 Ussuri release, this was called
+     ``hide_hypervisor_id``. An alias is provided to provide backwards
+     compatibility.
+
   .. code:: console
 
      $ openstack flavor set FLAVOR-NAME \
-         --property hide_hypervisor_id=VALUE
+         --property hw:hide_hypervisor_id=VALUE
 
   Where: