Description of problem:
1) The original SR-IOV locality implementation in Nova strictly enforces that if you are using an SR-IOV VF or PF and the NUMA filtering that the device must be attached to the same NUMA node(s) as the guest vCPUs. If no NUMA node with an appropriate device attached is available scheduling fails. Several customers have reported that while they would prefer NUMA locality they would not prefer it over scheduling at all.
2) In Newton support was added for VLAN aware virtual machines. This allows the parsing of a VLAN trunk and its subports to a instance, but the instantiation of the subports’ VLAN interfaces inside the guest is not automatic and there is no easy way to pass information about them to the instance.
3) Certain NFV workloads require the ability to perform trusted operations on a virtual function, such as enabling promiscuous mode or modifying the MAC address within the guest. This feature is available at the kernel, qemu, and libvirt level but is not exposed by OpenStack. Customers are able to workaround the lack of exposure at the OpenStack level manually but there is a danger that such workarounds may break in the future.