)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8ab1c4bbc78d1b8c37de10f1de7d28161ea9080d","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"conf: Deprecate \u0027devname\u0027 field of \u0027[pci] passthrough_whitelist\u0027"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This field has caused far too many issues, particularly when used with"},{"line_number":10,"context_line":"VFs. Deprecate it entirely and encourage people to use values that"},{"line_number":11,"context_line":"aren\u0027t as likely to change/not exist."},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"7faddb67_63ce232e","line":9,"range":{"start_line":9,"start_character":15,"end_line":9,"end_character":41},"updated":"2019-07-16 17:07:46.000000000","message":"This seems like a pretty intrusive change to be based on such a vague and unsubstantiated assertion. Are there bug reports or similar you could point to?","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fe03353b4db9ab5931e395def0f90a5c2971c2f3","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"conf: Deprecate \u0027devname\u0027 field of \u0027[pci] passthrough_whitelist\u0027"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This field has caused far too many issues, particularly when used with"},{"line_number":10,"context_line":"VFs. Deprecate it entirely and encourage people to use values that"},{"line_number":11,"context_line":"aren\u0027t as likely to change/not exist."},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"7faddb67_1831bc5a","line":9,"range":{"start_line":9,"start_character":15,"end_line":9,"end_character":41},"in_reply_to":"7faddb67_07cabb19","updated":"2019-07-18 13:55:58.000000000","message":"Cool, thanks for the explanation.\n\nSo I\u0027m sayin, it would be appropriate to have some of this context in the commit message.","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f80d5e24052c13b1067cbb1df205cdd9ab5f4ca7","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"conf: Deprecate \u0027devname\u0027 field of \u0027[pci] passthrough_whitelist\u0027"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This field has caused far too many issues, particularly when used with"},{"line_number":10,"context_line":"VFs. Deprecate it entirely and encourage people to use values that"},{"line_number":11,"context_line":"aren\u0027t as likely to change/not exist."},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"7faddb67_07cabb19","line":9,"range":{"start_line":9,"start_character":15,"end_line":9,"end_character":41},"in_reply_to":"7faddb67_63ce232e","updated":"2019-07-18 11:52:15.000000000","message":"yes.\n\nhere are 3 public downstream bugs\n\nhttps://bugzilla.redhat.com/show_bug.cgi?id\u003d1589796\nhttps://bugzilla.redhat.com/show_bug.cgi?id\u003d1590716\nhttps://bugzilla.redhat.com/show_bug.cgi?id\u003d1593290\n\nthose have all been closed at least oncec if not multiple times as wont fix on queens alone and there are other for other releases.\n\nwhen i was at intel i also had to deal with issues related to the use of devname. on older kernels e.g. ubuntu 14.04 or before the bios dev names stuff landed it was common for the\nvf or pf name top change after they were used by a vm\n\ne.g. eth3-\u003eeth10\n\neven with the predicable nic names in later kernels\ndepending on your udev rules the kernel/udev may not bind the PF or VF back to a nic driver and may instead elect to leave them bound to vfio-pci. if that happens the device wont have a netdev for the pf or vf and if your restart the nova compute agent it wont discover the device by its name and it will remove it from the pci resouce tracker.\n\nhttps://bugzilla.redhat.com/show_bug.cgi?id\u003d1589796 which is what is prompting stephen to submit is an instance of that last case were the nova compute agent container is restarted and it nolonger fineds the pfs/vfs.\n\n\nthis has been a pain in the ass since it was intoduced and i flat out ban using it in intel openstack reference architecture because it just could not be relied on which is why they always used the pci addres and or the vendor id/product id in the examples.\n \nhttps://01.org/sites/default/files/page/intel_onp_server_reference_architecture_guide_v1.4.pdf#%5B%7B%22num%22%3A98%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C69%2C552%2C0%5D\n\n\nthe other reason to remove it is it only works with nic.\n\nyou can have resonable device names for other types of pci device like pci ssd genrall have a device name but devname only works with nics where as all the other ways work for any device.","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8ab1c4bbc78d1b8c37de10f1de7d28161ea9080d","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"conf: Deprecate \u0027devname\u0027 field of \u0027[pci] passthrough_whitelist\u0027"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This field has caused far too many issues, particularly when used with"},{"line_number":10,"context_line":"VFs. Deprecate it entirely and encourage people to use values that"},{"line_number":11,"context_line":"aren\u0027t as likely to change/not exist."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: Ia9d3fc7f52ce55332ae392cd5a70269cc4f4bfcc"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"7faddb67_43d9a7f0","line":10,"range":{"start_line":9,"start_character":61,"end_line":10,"end_character":3},"updated":"2019-07-16 17:07:46.000000000","message":"Is it really just because of VFs? There are plenty of other kinds of PCI devices; are those problematic as well (problematic enough to warrant deprecating and removing this field)?","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"3e5aa6280f8d1bb39d2ae0d4fa28e8906236762f","unresolved":false,"context_lines":[{"line_number":7,"context_line":"conf: Deprecate \u0027devname\u0027 field of \u0027[pci] passthrough_whitelist\u0027"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This field has caused far too many issues as seen in multiple public"},{"line_number":10,"context_line":"downstream bugs [1][2][3]. Each of these have all been closed at least"},{"line_number":11,"context_line":"once, if not multiple times, as WONTFIX, and there are many other bugs,"},{"line_number":12,"context_line":"public and private and for varying versions."},{"line_number":13,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fa7e38b_2f4c26c6","line":10,"range":{"start_line":10,"start_character":16,"end_line":10,"end_character":25},"updated":"2019-09-18 12:33:41.000000000","message":"got access to just [1] but if they are all the same then it happens only with Inter hardware ? (havent encountered with mellanox hardware)","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7332a498163852210efd6a409711a0c1b388e4b","unresolved":false,"context_lines":[{"line_number":7,"context_line":"conf: Deprecate \u0027devname\u0027 field of \u0027[pci] passthrough_whitelist\u0027"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This field has caused far too many issues as seen in multiple public"},{"line_number":10,"context_line":"downstream bugs [1][2][3]. Each of these have all been closed at least"},{"line_number":11,"context_line":"once, if not multiple times, as WONTFIX, and there are many other bugs,"},{"line_number":12,"context_line":"public and private and for varying versions."},{"line_number":13,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fa7e38b_c3b689da","line":10,"range":{"start_line":10,"start_character":16,"end_line":10,"end_character":25},"in_reply_to":"3fa7e38b_2f4c26c6","updated":"2019-09-18 15:02:39.000000000","message":"the specific bug were releated to intel nics.\nits not intel specific i have seen this happen with connectx-3 nics in the past.\n\nin older releases of nova if a VF was in use by a vm and you restarted the compute agent it would not find the vf by it devname since it was bound to the vm and it would delete the entry from the db.\n\nnow we have recently fixed that and backported it but that behavior affected all vendors.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b814277bb29877007732003861951668eaf4d837","unresolved":false,"context_lines":[{"line_number":16,"context_line":"it was common for the name of a VF or PF to change after they were used"},{"line_number":17,"context_line":"by a VM (e.g. eth3-\u003eeth10). Even with the predictable devnames present"},{"line_number":18,"context_line":"in later kernels, some udev configurations may result in the kernel/udev"},{"line_number":19,"context_line":"not bind the PF or VF back to a NIC driver and may instead elect to"},{"line_number":20,"context_line":"leave them bound to \u0027vfio-pci\u0027, meaning the device won\u0027t have a netdev"},{"line_number":21,"context_line":"for the device. This breaks the PCI resource tracker (this was the cause"},{"line_number":22,"context_line":"of [1]). Finally, while the rest of the fields work with all types of"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"7faddb67_177f42ab","line":19,"range":{"start_line":19,"start_character":4,"end_line":19,"end_character":8},"updated":"2019-07-18 20:31:26.000000000","message":"binding","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7332a498163852210efd6a409711a0c1b388e4b","unresolved":false,"context_lines":[{"line_number":16,"context_line":"it was common for the name of a VF or PF to change after they were used"},{"line_number":17,"context_line":"by a VM (e.g. eth3-\u003eeth10). Even with the predictable devnames present"},{"line_number":18,"context_line":"in later kernels, some udev configurations may result in the kernel/udev"},{"line_number":19,"context_line":"not bind the PF or VF back to a NIC driver and may instead elect to"},{"line_number":20,"context_line":"leave them bound to \u0027vfio-pci\u0027, meaning the device won\u0027t have a netdev"},{"line_number":21,"context_line":"for the device. This breaks the PCI resource tracker (this was the cause"},{"line_number":22,"context_line":"of [1]). Finally, while the rest of the fields work with all types of"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fa7e38b_4f55e24f","line":19,"range":{"start_line":19,"start_character":4,"end_line":19,"end_character":8},"in_reply_to":"7faddb67_177f42ab","updated":"2019-09-18 15:02:39.000000000","message":"Done","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"}],"nova/compute/manager.py":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8ab1c4bbc78d1b8c37de10f1de7d28161ea9080d","unresolved":false,"context_lines":[{"line_number":1250,"context_line":"                # every time we parse a whitelist (which happens in a few"},{"line_number":1251,"context_line":"                # places in the code)"},{"line_number":1252,"context_line":"                LOG.warning("},{"line_number":1253,"context_line":"                    \"The use of the \u0027devname\u0027 field in the \u0027[pci] whitelist\u0027 \""},{"line_number":1254,"context_line":"                    \"config option value is deprecated and will be removed in \""},{"line_number":1255,"context_line":"                    \"a future release. Use either the \u0027address\u0027 field or the \""},{"line_number":1256,"context_line":"                    \"\u0027vendor_id\u0027 and \u0027product_id\u0027 fields instead\")"}],"source_content_type":"text/x-python","patch_set":1,"id":"7faddb67_83855fd1","line":1253,"range":{"start_line":1253,"start_character":66,"end_line":1253,"end_character":75},"updated":"2019-07-16 17:07:46.000000000","message":"passthrough_whitelist","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"6ca5ce12daa5edd2413a6068b848e80d31cf04db","unresolved":false,"context_lines":[{"line_number":1250,"context_line":"                # every time we parse a whitelist (which happens in a few"},{"line_number":1251,"context_line":"                # places in the code)"},{"line_number":1252,"context_line":"                LOG.warning("},{"line_number":1253,"context_line":"                    \"The use of the \u0027devname\u0027 field in the \u0027[pci] whitelist\u0027 \""},{"line_number":1254,"context_line":"                    \"config option value is deprecated and will be removed in \""},{"line_number":1255,"context_line":"                    \"a future release. Use either the \u0027address\u0027 field or the \""},{"line_number":1256,"context_line":"                    \"\u0027vendor_id\u0027 and \u0027product_id\u0027 fields instead\")"}],"source_content_type":"text/x-python","patch_set":1,"id":"7faddb67_a85db379","line":1253,"range":{"start_line":1253,"start_character":66,"end_line":1253,"end_character":75},"in_reply_to":"7faddb67_83855fd1","updated":"2019-07-18 15:57:02.000000000","message":"Done","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8ab1c4bbc78d1b8c37de10f1de7d28161ea9080d","unresolved":false,"context_lines":[{"line_number":1253,"context_line":"                    \"The use of the \u0027devname\u0027 field in the \u0027[pci] whitelist\u0027 \""},{"line_number":1254,"context_line":"                    \"config option value is deprecated and will be removed in \""},{"line_number":1255,"context_line":"                    \"a future release. Use either the \u0027address\u0027 field or the \""},{"line_number":1256,"context_line":"                    \"\u0027vendor_id\u0027 and \u0027product_id\u0027 fields instead\")"},{"line_number":1257,"context_line":"                break"},{"line_number":1258,"context_line":""},{"line_number":1259,"context_line":"        nova.conf.neutron.register_dynamic_opts(CONF)"}],"source_content_type":"text/x-python","patch_set":1,"id":"7faddb67_236eeb2e","line":1256,"range":{"start_line":1256,"start_character":63,"end_line":1256,"end_character":64},"updated":"2019-07-16 17:07:46.000000000","message":"d.","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"6ca5ce12daa5edd2413a6068b848e80d31cf04db","unresolved":false,"context_lines":[{"line_number":1253,"context_line":"                    \"The use of the \u0027devname\u0027 field in the \u0027[pci] whitelist\u0027 \""},{"line_number":1254,"context_line":"                    \"config option value is deprecated and will be removed in \""},{"line_number":1255,"context_line":"                    \"a future release. Use either the \u0027address\u0027 field or the \""},{"line_number":1256,"context_line":"                    \"\u0027vendor_id\u0027 and \u0027product_id\u0027 fields instead\")"},{"line_number":1257,"context_line":"                break"},{"line_number":1258,"context_line":""},{"line_number":1259,"context_line":"        nova.conf.neutron.register_dynamic_opts(CONF)"}],"source_content_type":"text/x-python","patch_set":1,"id":"7faddb67_4858bf86","line":1256,"range":{"start_line":1256,"start_character":63,"end_line":1256,"end_character":64},"in_reply_to":"7faddb67_236eeb2e","updated":"2019-07-18 15:57:02.000000000","message":"Done","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"}],"nova/conf/pci.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"79dbb9f4c1704cc45a7d1d365c81091f0c906c59","unresolved":false,"context_lines":[{"line_number":122,"context_line":"    PCI devices have a name."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"    This has been deprecated due to a number of issues, particularly when used"},{"line_number":125,"context_line":"    with VFs or on older kernel. In addition, it only ever worked with NICs."},{"line_number":126,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":127,"context_line":"    fields instead."},{"line_number":128,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"3fa7e38b_9976e73e","line":125,"range":{"start_line":125,"start_character":25,"end_line":125,"end_character":31},"updated":"2019-09-16 20:02:46.000000000","message":"kernels or \"on an older kernel\"","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"}],"releasenotes/notes/deprecate-pci-passthrough_whitelist-dev_name-5663a0da6c481b78.yaml":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8ab1c4bbc78d1b8c37de10f1de7d28161ea9080d","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    The ``dev_name`` field of the ``[pci] passthrough_whitelist`` config option"},{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons, chief"},{"line_number":6,"context_line":"    among them being that with some NICs, the kernel may not bind a Virtual"},{"line_number":7,"context_line":"    Functions (VFs) back to the network driver, instead leaving it bound to"},{"line_number":8,"context_line":"    ``vfio-pci``, meaning the VF will not be re-associated with its previous"},{"line_number":9,"context_line":"    devname. Use either the ``address`` field or the ``vendor_id`` and"},{"line_number":10,"context_line":"    ``product_id`` fields."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"7faddb67_43544753","line":7,"range":{"start_line":6,"start_character":66,"end_line":7,"end_character":19},"updated":"2019-07-16 17:07:46.000000000","message":"a Virtual Function (VF)\n\nor\n\nVirtual Functions (VFs)","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"6ca5ce12daa5edd2413a6068b848e80d31cf04db","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    The ``dev_name`` field of the ``[pci] passthrough_whitelist`` config option"},{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons, chief"},{"line_number":6,"context_line":"    among them being that with some NICs, the kernel may not bind a Virtual"},{"line_number":7,"context_line":"    Functions (VFs) back to the network driver, instead leaving it bound to"},{"line_number":8,"context_line":"    ``vfio-pci``, meaning the VF will not be re-associated with its previous"},{"line_number":9,"context_line":"    devname. Use either the ``address`` field or the ``vendor_id`` and"},{"line_number":10,"context_line":"    ``product_id`` fields."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"7faddb67_082de7a6","line":7,"range":{"start_line":6,"start_character":66,"end_line":7,"end_character":19},"in_reply_to":"7faddb67_43544753","updated":"2019-07-18 15:57:02.000000000","message":"Rewrote this whole thing per Sean\u0027s comment","commit_id":"2abda477f258bc319bb3233493d5e0e1d83b6ea9"}],"releasenotes/notes/deprecate-pci-passthrough_whitelist-devname-5663a0da6c481b78.yaml":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"79dbb9f4c1704cc45a7d1d365c81091f0c906c59","unresolved":false,"context_lines":[{"line_number":2,"context_line":"deprecations:"},{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    The ``devname`` field of the ``[pci] passthrough_whitelist`` config option"},{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"    - On older kernels, such as Ubuntu 14.04, where a feature that enabled"},{"line_number":8,"context_line":"      persistent devnames still hadn\u0027t landed, it was common for the name of a"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_19aaf784","line":5,"range":{"start_line":5,"start_character":25,"end_line":5,"end_character":29},"updated":"2019-09-16 20:02:46.000000000","message":"This field","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"79dbb9f4c1704cc45a7d1d365c81091f0c906c59","unresolved":false,"context_lines":[{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"    - On older kernels, such as Ubuntu 14.04, where a feature that enabled"},{"line_number":8,"context_line":"      persistent devnames still hadn\u0027t landed, it was common for the name of a"},{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_b99ac36b","line":8,"range":{"start_line":8,"start_character":32,"end_line":8,"end_character":38},"updated":"2019-09-16 20:02:46.000000000","message":"Avoid contractions in docs.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"3e5aa6280f8d1bb39d2ae0d4fa28e8906236762f","unresolved":false,"context_lines":[{"line_number":4,"context_line":"    The ``devname`` field of the ``[pci] passthrough_whitelist`` config option"},{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"    - On older kernels, such as Ubuntu 14.04, where a feature that enabled"},{"line_number":8,"context_line":"      persistent devnames still hadn\u0027t landed, it was common for the name of a"},{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_5719fa76","line":10,"range":{"start_line":7,"start_character":6,"end_line":10,"end_character":17},"updated":"2019-09-18 12:33:41.000000000","message":"according to TC[1] only latest ubuntu LTS is supported, why are you mentioning such an old OS ?\n\n[1]https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"019f45e32cd1caab46485659f6175877aa7c2764","unresolved":false,"context_lines":[{"line_number":4,"context_line":"    The ``devname`` field of the ``[pci] passthrough_whitelist`` config option"},{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"    - On older kernels, such as Ubuntu 14.04, where a feature that enabled"},{"line_number":8,"context_line":"      persistent devnames still hadn\u0027t landed, it was common for the name of a"},{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_d77dd56e","line":10,"range":{"start_line":7,"start_character":6,"end_line":10,"end_character":17},"in_reply_to":"3fa7e38b_03c341ef","updated":"2019-09-19 06:57:58.000000000","message":"i see, however if i understand the structure of what you wrote. this is a reason explaining why devname is problematic, however seeing that such old kernels are not supported by openstack, that\u0027s not really a reason right ?\n\nanyway, i get what you are trying to convey here.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7332a498163852210efd6a409711a0c1b388e4b","unresolved":false,"context_lines":[{"line_number":4,"context_line":"    The ``devname`` field of the ``[pci] passthrough_whitelist`` config option"},{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"    - On older kernels, such as Ubuntu 14.04, where a feature that enabled"},{"line_number":8,"context_line":"      persistent devnames still hadn\u0027t landed, it was common for the name of a"},{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_03c341ef","line":10,"range":{"start_line":7,"start_character":6,"end_line":10,"end_character":17},"in_reply_to":"3fa7e38b_5719fa76","updated":"2019-09-18 15:02:39.000000000","message":"to provide context. this is not a new thing i have wanted to deprecate this for years.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"97f6074b89d6ed64958b61f55005da31fb728f41","unresolved":false,"context_lines":[{"line_number":4,"context_line":"    The ``devname`` field of the ``[pci] passthrough_whitelist`` config option"},{"line_number":5,"context_line":"    has been deprecated. This is problematic for a number of reasons."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"    - On older kernels, such as Ubuntu 14.04, where a feature that enabled"},{"line_number":8,"context_line":"      persistent devnames still hadn\u0027t landed, it was common for the name of a"},{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_779864bf","line":10,"range":{"start_line":7,"start_character":6,"end_line":10,"end_character":17},"in_reply_to":"3fa7e38b_d77dd56e","updated":"2019-09-23 18:13:16.000000000","message":"ubuntu 14.04 shipped originally with kernel 3.13 and was a newer kernel then centos 7.0 which is based on 3.10.\n\nthe kernel and systemd changes to use bios dev names or consistent systemd names i belive only started to be shipped for 7.3. we still have downstream customer that have really old deployments that we have to support.\n\ni feel like i should also ping out that if you do not have\nhttps://review.opendev.org/#/c/626381/5 applied then it is fundementally unsafe to use devname.\n\nwithout that change if you restart the compute agent while\nthe vm is activlying using a vf that was whiltlist using devname, then the vf will be removed form the database.\n\nif the vm i later stopped, the vf would be rebound to the host and rediscovered by the pci track and added as free.\n\nthen a second instance can be schduled to the same vf in a similar way to what is described in the bug https://bugs.launchpad.net/nova/+bug/1633120\n\nmeaning if you start the first vm again it will cause one or both of the vms to crash as both attempt to use the same VF.\n\nthis is now fixed which is why i did not bring it up initially but for years it was totally broken to restart the compute service whiele any vm was using a pci device that was whitelisted via devname.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b814277bb29877007732003861951668eaf4d837","unresolved":false,"context_lines":[{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"7faddb67_1758a253","line":13,"range":{"start_line":13,"start_character":55,"end_line":13,"end_character":59},"updated":"2019-07-18 20:31:26.000000000","message":"binding","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"79dbb9f4c1704cc45a7d1d365c81091f0c906c59","unresolved":false,"context_lines":[{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_798e8b2f","line":15,"range":{"start_line":15,"start_character":39,"end_line":15,"end_character":44},"updated":"2019-09-16 20:02:46.000000000","message":"sane","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"3e5aa6280f8d1bb39d2ae0d4fa28e8906236762f","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_774af627","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"updated":"2019-09-18 12:33:41.000000000","message":"on which hardware does this happen ? is this vendor specific ? i haven\u0027t encountered this when deploying on Mellanox hardware.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"f0f319d5993425dff42f2bd0cab470d3c8db3b7d","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_ab89a6ca","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"in_reply_to":"3fa7e38b_23b756d8","updated":"2019-09-22 10:54:52.000000000","message":"According to [1] libvirt relies on some device manager (e.g udev) to determine the driver.\n\nNow, Did some grepping in libvirt code and it seems that while upper layer code does allow to specify which driver to re-attach a device to, the decision eventually is left to the system (udev) with an exception listed in [2].\n\nSean, can you provide a bit more context on the issues you faced with udev/kernel ?\n\nIf \u0027devname\u0027 brings more harm than good, then i\u0027m all for removing it.\n\n\n[1]https://libvirt.org/drvnodedev.html\n[2]https://github.com/libvirt/libvirt/blob/6bb4242d9fe0385e6a62db37e6f93df3fa33e930/src/libxl/libxl_driver.c#L5820","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"c9883022f272c998750a4e01446cf62765805d77","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_1168dd84","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"in_reply_to":"3fa7e38b_4410dfa8","updated":"2019-09-26 08:21:06.000000000","message":"\u003e so dont take away the view we can rely on netdev names for neutorn\n \u003e in general but sriov can expose edgecase that dont otherwise\n \u003e happen.\n\nMy view is that we should be able to rely on persistent netdev name assuming the system is properly configured in both neutron and nova.\n\nAlso i\u0027m not too sure on how common it is to Passthrough an SR-IOV PF these days.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},"change_message_id":"9de01e79139f4d4333fea2a287e568cdb976cdf8","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_23b756d8","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"in_reply_to":"3fa7e38b_5e126e5a","updated":"2019-09-18 20:48:05.000000000","message":"really, Did you check that with libvirt community?\n\n\nMy understand is that libvirt always tries to bring config to old state once VF it is detached from guest.\n\nfrom [1] \n\"\nSimilar to the functionality of a standard \u003chostdev\u003e device, when managed is \"yes\", it is detached from the host before being passed on to the guest, and reattached to the host after the guest exits.\n\nand nodedev-reattach see [2] \"Reattach a node device to its device driver, once released by the guest domain\".\n\nIs it possible you hit a libvirt bug?\n\n[1] https://libvirt.org/formatdomain.html\n[2] https://libvirt.org/sources/virshcmdref/html/sect-nodedev-reattach.html","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7332a498163852210efd6a409711a0c1b388e4b","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_5e126e5a","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"in_reply_to":"3fa7e38b_774af627","updated":"2019-09-18 15:02:39.000000000","message":"this depend on your host configuration and is driver sepcific. when the libvirt will automaticaly bind the VF to vfio-pci wehn it attaches it to the guest. its up to the kernel/udev to decide to bind it back to a nic driver after its detached form teh guest but its not required to do that. its perfectly valid to leave it bound to vfio-pci.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"35f618e6c31ec22a9b1d59f310084bf4e5e22268","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_81ded40e","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"in_reply_to":"3fa7e38b_77ddc46e","updated":"2019-09-25 10:56:40.000000000","message":"Thank you for providing context.\nWhat i understand, aside of a solved bug in nova, is that getting persistent netdev naming to work is a pain, specifically for old OSes and kernel.\n\nbut if we say that having persistent naming is a prerequisite of the system, then we OK (from Nova side at least).\n\nTake for example, in the case of provider network[1][2] neutron relies (indirectly) on persistent naming since you need to make sure that we have a physical NIC connected to the bridge (br-phys) right?\n\nfrom an upstream perspective, i would send a heads-up mail with a deprecation notice to get some feedback.\n\nfrom a downstream perspective, as you explained before, the deployment folks will need to deal with it in case there are customers who rely on this ability.\n\n\n[1]https://docs.openstack.org/neutron/pike/admin/deploy-ovs-provider.html\n[2]https://docs.openstack.org/ocata/networking-guide/deploy-lb-provider.html","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d9864808643486cd22d46b90d996bd364a3ff821","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_4410dfa8","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"in_reply_to":"3fa7e38b_81ded40e","updated":"2019-09-25 19:44:56.000000000","message":"persistent naming using systemd or biosdevnames\ngenerall just works so this has no implciation for standard ovs. the issue is with PCI hotplug which is effectily what happens when you do a sriov PF or VF passthouhg.\n\nso dont take away the view we can rely on netdev names for neutorn in general but sriov can expose edgecase that dont otherwise happen.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"97f6074b89d6ed64958b61f55005da31fb728f41","unresolved":false,"context_lines":[{"line_number":9,"context_line":"      VF or PF to change after they were used by a VM (e.g. ``eth3`` to"},{"line_number":10,"context_line":"      ``eth10``)."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    - Even with the predictable devnames present in later kernels, some udev"},{"line_number":13,"context_line":"      configurations may result in the kernel/udev not bind the PF or VF back"},{"line_number":14,"context_line":"      to a NIC driver and may instead elect to leave them bound to"},{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_77ddc46e","line":16,"range":{"start_line":12,"start_character":6,"end_line":16,"end_character":38},"in_reply_to":"3fa7e38b_ab89a6ca","updated":"2019-09-23 18:13:16.000000000","message":"there are two factors at play here.\n1. will a pf/vf be bound to a nic driver or left with vfio-pci \n2 if the device is bound back to a nic driver will it get a consitent name.\n\nthe question of will it the nic be bound to a nic driver instad of vfio-pci depend on a number of factors\n\n1 which of the following are you using to manage your devices udev, systemd-udevd, mdev/buysbox-mdev\n2 have you defined any custom udev rules\n3 your device vendor/kernel driver version\n4 has /sys/class/net/*/device/driver_override been modifed since system boot.\n5 have you blacklisted any dirvers using modeprobe setting.\n\ngenerally if you do 4 or 5 then you wont be using devnames\nas its more or less mutally exclsive.\n\n\nassuming your device manger will attempt to bind the pf/vf back to a nic driver then that brings use to the second point. consistent names.\n\nThe changes that enable consitent device nameing are partly kernel dependant but also depend on a few other factors.\nfirstly there are several supported nameing schemes\nhttps://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming\n\nform a rhel/centos perspective the kernel nameing scheme (Scheme 5) changes between rhel 7.2 and 7.3 due to backport for the upstream  4.x series. \n\nthe primary factors that effect how your device will be named are as follows:\n\n1 do you have a new enought smbios and firmware to support biosdevnames\n2 is biosdevnames installed\n3 is your systemd new enough to use it own consistent nameing scheme\n4 is the bug related to having both biosdevnames and systemd-udev fixed\n5 are you on rhel 7.3+ and still have net.ifnames\u003d0 biosdevname\u003d0 see https://bugzilla.redhat.com/show_bug.cgi?id\u003d1425787\n\npoint number 5 is what used to be the most common cause\nof issue with devname. reverting to the ETH* names is/was supported when people first deployed on centos 7 and while we not recommend against doign this many customer that ignored that recommentation expericen issue with devname.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"3e5aa6280f8d1bb39d2ae0d4fa28e8906236762f","unresolved":false,"context_lines":[{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_3d545fca","line":19,"range":{"start_line":18,"start_character":5,"end_line":19,"end_character":45},"updated":"2019-09-18 12:33:41.000000000","message":"This statement is not correct, what about physical_network ? thats also a NIC feature.\n\nmy take here is that passthrough whitelist has evolved to contain NIC attributes.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7332a498163852210efd6a409711a0c1b388e4b","unresolved":false,"context_lines":[{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_8373b1e7","line":19,"range":{"start_line":18,"start_character":5,"end_line":19,"end_character":45},"in_reply_to":"3fa7e38b_3d545fca","updated":"2019-09-18 15:02:39.000000000","message":"pyhical network is a tag not a filed use for filtering.\nthey are two different things","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"019f45e32cd1caab46485659f6175877aa7c2764","unresolved":false,"context_lines":[{"line_number":15,"context_line":"      ``vfio-pci``, meaning the device won\u0027t have a netdev for the device. This"},{"line_number":16,"context_line":"      breaks the PCI resource tracker."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_37a0e9f4","line":19,"range":{"start_line":18,"start_character":5,"end_line":19,"end_character":45},"in_reply_to":"3fa7e38b_8373b1e7","updated":"2019-09-19 06:57:58.000000000","message":"I see, thanks for clarifying.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"3e5aa6280f8d1bb39d2ae0d4fa28e8906236762f","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_ef992e1f","line":21,"range":{"start_line":21,"start_character":44,"end_line":21,"end_character":76},"updated":"2019-09-18 12:33:41.000000000","message":"This will not work in case of multiple NICs of the same vendor:product connected to different physnets","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"3e5aa6280f8d1bb39d2ae0d4fa28e8906236762f","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_cfbd5269","line":21,"range":{"start_line":21,"start_character":18,"end_line":21,"end_character":28},"updated":"2019-09-18 12:33:41.000000000","message":"what about SR-IOV on dual port NICs connected to different physnets ?","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"019f45e32cd1caab46485659f6175877aa7c2764","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_97e67d16","line":21,"range":{"start_line":21,"start_character":44,"end_line":21,"end_character":76},"in_reply_to":"3fa7e38b_a3458d72","updated":"2019-09-19 06:57:58.000000000","message":"So the approach is to tailor using PCI regex, can\u0027t imagine it would be fun during deployment.\n\nalso im not sure VF PCI enumeration behaves the same on all hardware. \n\nAnyway, during deployment, one could inspect sys/bus/pci/devices/\u003cPF-D:B:D.f\u003e/virtfn*\nand create the appropriate whitelist.\n\nOne caveat that i can think of is scaling up/down sriov VFs will require whitelist update in some cases.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7332a498163852210efd6a409711a0c1b388e4b","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_a3458d72","line":21,"range":{"start_line":21,"start_character":44,"end_line":21,"end_character":76},"in_reply_to":"3fa7e38b_ef992e1f","updated":"2019-09-18 15:02:39.000000000","message":"for that usecase you need to use the pci address.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"change_message_id":"3e5aa6280f8d1bb39d2ae0d4fa28e8906236762f","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_0ffdaa39","line":22,"range":{"start_line":21,"start_character":3,"end_line":22,"end_character":11},"updated":"2019-09-18 12:33:41.000000000","message":"What is the recommendation for SR-IOV deployments e.g with TripleO? define SR-IOV role per server type ?","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c7332a498163852210efd6a409711a0c1b388e4b","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    - While the rest of the filters work with all types of PCI devices, the"},{"line_number":19,"context_line":"      ``devname`` field only works with NICs."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Use either the ``address`` field or the ``vendor_id`` and ``product_id``"},{"line_number":22,"context_line":"    fields."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_c318c982","line":22,"range":{"start_line":21,"start_character":3,"end_line":22,"end_character":11},"in_reply_to":"3fa7e38b_0ffdaa39","updated":"2019-09-18 15:02:39.000000000","message":"possibly, i avoid trippleo where i can.\n\nwe intend to drop support for this parmater downstream in OSP in the next LTS release of OSP. triplo may continue to supprot it but we are updaing our documentiaon to recmonned that it is not used. we may need to work with our deployment folks to ensure there is an easy replacement but even today we recommend using the pci address rexex capablity with the vendor id and product id not the devname.","commit_id":"6c1aaf27d836f7b16b826e8ec6276d1a4d2edbc5"}]}