hi
just following up form yesterday.
i just finished testing the pci numa policy feature
and i can confirm that the prefer policy which allow use of non
local pci devices does not work.
the test case was relitively simple
1 host with 2 numa nodes
1 pci device attach to numa node 0
and vcpu pin set configured to allow only numa node 1
in this case booting a vm with a passthrough alias and a passthrough alias
fails.
[stack@cloud-3 devstack]$ openstack flavor show 42
+----------------------------+-----------------------------------------------------+
| Field | Value
|
+----------------------------+-----------------------------------------------------+
| OS-FLV-DISABLED:disabled | False
|
| OS-FLV-EXT-DATA:ephemeral | 0
|
| access_project_ids | None
|
| disk | 0
|
| id | 42
|
| name | m1.nano
|
| os-flavor-access:is_public | True
|
| properties | hw:numa_nodes='1',
pci_passthrough:alias='nic-pf:1' |
| ram | 64
|
| rxtx_factor | 1.0
|
| swap |
|
| vcpus | 1
|
+----------------------------+-----------------------------------------------------+
passthrough_whitelist = { "address": "0000:01:00.1" }
alias = { "vendor_id":"8086", "product_id":"10c9", "device_type":"type-PF",
"name":"nic-pf", "numa_policy": "preferred"}
removeing the hw:numa_nodes='1' extra spec allow the vm to boot as it nolonger
has a numa topology.
the vm passes scheduling in both casess but when the vm has a virtual numa
toplogy of 1 node
we fail in the resocue tracker on the compute node when claiming resouces for
the instance.
i will submit a bug for this and repose the spec next week to track closing
this gap.
On Thu, 2018-11-22 at 03:20 +0000, Xu, Chenjie wrote:
> Hi Miguel,
> There is another RFE “Add l2pop support for floating IP resources” proposed
> to Launchpad. This RFE also comes from
> StarlingX and the link is below:
> https://bugs.launchpad.net/neutron/+bug/1803494
> Could you please help review this RFE? I think this RFE can be added to the
> gap analysis. What’s more, there is a bug
> and a RFE relating to l2pop and neutron-dynamic-routing is being written and
> is expected to be released next week.
>
> Best Regards,
> Xu, Chenjie
>
> From: Miguel Lavalle [mailto:mig...@mlavalle.com]
> Sent: Thursday, November 22, 2018 2:12 AM
> To: openstack-disc...@lists.openstack.org; OpenStack Development Mailing List
> <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack
> master
>
> Hi Stackers,
>
> One of the key goals of StarlingX during the current cycle is to converge
> with the OpenStack projects master branches.
> In order to accomplish this goal, the Technical Steering Committee put
> together a gap analysis that shows the specs
> and patches that need to merge in the different OpenStack projects by the end
> of Stein. The attached PDF document
> shows this analysis. Although other projects are involved, most of the work
> has to be done in Nova, Neutron and
> Horizon. Hopefully all the involved projects will help StarlingX achieve this
> important goal.
>
> It has to be noted that work is still on-going to refine this gap analysis,
> so there might be some updates to it in
> the near future.
>
> Best regards
>
> Miguel
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
