Known Issues and Limitations

Release Specific Issues Live migration fails on ThunderX nodes with different CPU Revisions Description and Impact: For an aarch64 architecture, QEMU describes a CPU in terms of Vendor, Model and Revision number in contrast with the x86 architecture, where CPU supported features (e.g. the instruction set supported) are used. QEMU lacks support in describing a CPU in terms of features for an aarch64 architecture, causing the migration of VMs between hosts with different CPU revisions to fail. Workaround: In the deployment pod use compute nodes with the same Vendor, Model, and Revision number CPUs. ThunderX integrated NICs cannot be used for SR-IOV Description and Impact: For the moment ENEA NFV Core is missing the support to configure ThunderX integrated NICs for deployment. Furthermore, ThunderX integrated NICs cannot be used for SR-IOV even if configured manually after deployment. This happens because ThunderX integrated NICs are themseleves virtual functions and are incorrectly handled by libvirt when trying to assign them to a virtual machine. It is however possible to deploy with SR-IOV over add-on interfaces via the PCI-E expansion slots. Workaround: there is no workaround for this issue. As an alternative, the user can configure an external PCI-E NIC for SR-IOV. ThunderX integrated NICs cannot be used for PCI passthrough with direct-physical bound Neutron ports Description and Impact: PCI Passthrough using direct-physical bound ports also uses the neutron-sriov-agent. Because the interfaces are represented as virtual functions, it will be impossible to use Neutron ports bound as direct-physical (the Nova driver will identify them as type-VF, not type-PF). Due to this, it is not possible to claim PCI devices using direct-physical bound ports. It is however possible to passthrough any device using the PCI alias method, which requries configuring a whitelist of PCI devices and assigning an alias which is set as metadata in the Nova flavor. Workaround: There is no workaround for this issue. As an alternative, the user can configure a PCI alias instead. Scale-in and Scale-out operations are not supported Description and Impact: When adding or removing nodes via Fuel installer on an OPNFV deployment that uses OpenDaylight, flows in ovs tables on the existing and new nodes are not updated properly. Similarly, OpenvSwitch ports interfaces are not removed when deleting nodes. As a consequence, when adding a compute node to an existing OPNFV deployment, the instances running on the new compute node cannot be reached by floating IP. Scale-out and scale-in operations are flawed. Workaround: The rules can be manually configured, but this is not scalable. Hot-plugging network interfaces does not work in aarch64 guests Description and Impact: When the user tries to hot-plug a network port to a running instance, this fails due to virtio negotiation failure between the host and guest. This happens when the VM is using a Linux Kernel version prior to 4.10. Port addition or deletion is not possible. This reproduces on aarch64. Workaround: The user needs to upgrade the guest Linux Kernel to 4.10 or later. In case of port addition, the user also needs to manually set the link up and trigger the dhclient request. Fuel Healthcheck Configuration tests fail when default credentials are used Description and Impact: The Configuration tests from the Fuel Healthcheck fail when the OPNFV cluster operates with the default credentials. This has no impact on the overall cluster functionality. This is architecture independent. Workaround: In order to make these 3 test cases pass, the user needs to: Change the credentials for the root user on the Fuel Master node: after logging on as root on the master node, issue command passwd and provide the new password. Change the default credentials for the OpenStack cluster: in Fuel Dashboard, for an Environment, change Settings|General|OpenStack Access > Password to something other than the default. Change the default credentials for Keystone on the master node: in Fuel Dashboard, click on the user avatar and select Change Password. This should be done before deploy or you will need to redeploy to have the changes applied. Offline Deploy with Fuel fails at times Description and Impact: The Postfix installation and post-install configuration sometimes take longer when the Fuel deployment is performed without Internet connectivity. The tools Puppet task has a 5 minute completion timeout, causing there to not be enough time left for the other components of the tools task to be executed. Workaround: Simply press Deploy changes again. Since by now Postfix is installed, it will skip the installation and finish in time. Volumes fail to attach during the first few seconds of a VM booting procedure Description and Impact: There is a short period of a few seconds after a VM stated the boot procedure when attaching an external volume will result in an error to claim the qemu assigned bus in the guest Image kernel. Disks attached in the first few seconds of the booting procedure of a VM, will fail to register in the guest VM. Workaround: Attach volumes to a VM only before the VM is booting or after the period of a few seconds has passed since the booting procedure started. On Mixed Arch Deployment, only the aarch64 TestVM Cirros image will be installed by Fuel Description and Impact: Due to the fact that Fuel will only deploy the aarch64 image, Yardstick, Functest, and certain Health Check tests will not work. These test suites are dependent on a single image name at a time, and do not know on how to place instances on the Compute for images that each require a different arch. To have both testVM images, the user must add the x86_64 image manually. There is no workaround for the test suites failures. Removing QoS policies is unreliable Description and Impact: When removing per port bandwidth limiting QoS policies, all traffic is suddenly dropped. On the the other hand, when removing QoS policies configured at Openstack network level, traffic flows as if the rules are still there. There is no workaround. Enabling Ceph for Glance and Nova ephemeral storage makes the deployment fail on aarch64 Description and Impact: There are multiple configurable Storage Backends in Fuel settings. Enabling Ceph RBD for images (Glance) and Ceph RBD for ephemeral volumes (Nova), makes the deployment fail at the CEPH Ready Check performed on the primary Controller node. This only occurs when using aarch64 nodes; on x86_64, deployment does not fail There is no workaround. The user should not enable these options.