Hey OpenStackers, I’ve recently found out, that changing of use neutron sriov-agent in Mitaka from optional to required[1] makes a kind of regression. Before Mitaka, there was possible to use any number of NICs with one Neutron physnet just by specifying pci_passthrough_whitelist in nova:
[default]
pci_passthrough_whitelist = { "devname": "eth3", "physical_network":
"physnet2”},{ "devname": "eth4", "physical_network": "physnet2”},
which means, that eth3 and eth4 will be used for physnet2 in some manner.
In Mitaka, there also required to setup neutron sriov-agent as well:
[sriov_nic]
physical_device_mappings = physnet2:eth3
The problem actually is to unable to specify this mapping as
"physnet2:eth3,physnet2:eth4” due to implementation details, so it is clearly a
regression.
I’ve filed bug[2] for it and proposed a patch[3]. Originally
physical_device_mappings is converted to dict, where physnet name goes to key,
and interface name to value:
>>> parse_mappings('physnet2:eth3’)
{‘physnet2’: 'eth3’}
>>> parse_mappings('physnet2:eth3,physnet2:eth4’)
ValueError: Key physnet2 in mapping: 'physnet2:eth4' not unique
I’ve changed it a bit, so interface name is stored in list, so now this case is
working:
>>> parse_mappings_multi('physnet2:eth3,physnet2:eth4’)
{‘physnet2’: [‘eth3’, 'eth4’]}
I’d like to see this fix[3] in master and Mitaka branch.
Moshe Levi also proposed to refactor this part of code to remove
physical_device_mappings and reuse data that nova provides somehow. I’ll file
the RFE as soon as I figure out how it should work.
[1]: http://docs.openstack.org/liberty/networking-guide/adv_config_sriov.html
[2]: https://bugs.launchpad.net/neutron/+bug/1558626
[3]: https://review.openstack.org/294188
--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
