Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2117148

Summary: RFE: nmstate shall support adding interfaces of type virtual-function using VF id and PF name
Product: Red Hat Enterprise Linux 9 Reporter: Karthik Sundaravel <ksundara>
Component: nmstateAssignee: Gris Ge <fge>
Status: CLOSED ERRATA QA Contact: Mingyu Shi <mshi>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.1CC: ferferna, jiji, jishi, network-qe, sfaye, till
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-09 07:31:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
verified.log none

Description Karthik Sundaravel 2022-08-10 06:50:05 UTC
Description of problem:

In order to enhance the user experience and ease of using virtual functions of SR-IOV for host networking, identifying the VFs by pf name and VF-id would help.
In os-net-config, a similar referencing is done already and OSP would benefit as well with this enhancement.

Sample nmstate configuration:
interfaces:
- name: eth3vf3
  type: virtual-function
  parent: <pf name>
  vfid: <vf id> 
  state: up
- name: ovs0
  type: ovs-interface
  state: up
  ipv4:
    enabled: true
    address:
      - ip: 192.0.2.1
        prefix-length: 24
- name: ovs-br0
  type: ovs-bridge
  state: up
  bridge:
    options:
      stp: true
    port:
    - name: eth3vf3
    - name: ovs0

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Gris Ge 2022-09-02 14:16:02 UTC
Hi Karthik,

In your example, you already have the interface name `eth3vf3` of VF. Can you just use it for static IP config, bridge/bond port attaching, etc?

After you indicating you want to configure specific VF without know its interface name before hand?

Comment 3 Gris Ge 2022-09-05 09:36:41 UTC
Hi Karthik,

Can you check whether this yaml meet your expectation?


---
interfaces:
- name: br0
  type: linux-bridge
  state: up
  bridge:
    port:
      - name: sriov:eth1:2
    options:
      stp:
        enabled: false
- name: bond99
  type: bond
  state: up
  link-aggregation:
    mode: balance-rr
    port:
    - sriov:eth1:2
    options:
      all_slaves_active: dropped
- name: sriov:eth1:3
  type: ethernet
  state: up
  mtu: 1500
  ipv4:
    enabled: false
  ipv6:
    enabled: false

Comment 4 Karthik Sundaravel 2022-09-05 09:43:57 UTC
Yes Gris, the intent is to be able to attach or configure a VF without knowing its name upfront.

The sample yaml you have shared meets the expectation.

Comment 5 Gris Ge 2022-09-06 14:17:36 UTC
Hi Karthik,

Once more question, there is a use case where in __single__ transaction, people can enable/increase SR-IOV total_vfs count along with using the future VF at the same time.

Currently, nmstate will fail because it cannot resolve `sriov:eth1:1` as it does not exist yet, user have to first change `total_vfs`, then refer it in another apply action.

To support this __single__ transaction, big changes will be needed and that code will be only used for this corner case.

Comment 6 Karthik Sundaravel 2022-09-06 15:24:52 UTC
Hi Gris,

Yes I understand the sequence of transactions. Today we don't have a need to do everything in the same transaction, however if there is a need later it could be a new RFE.

Comment 7 Gris Ge 2022-09-08 06:41:57 UTC
Patch posted to upstream: https://github.com/nmstate/nmstate/pull/2030

Introduced special interface name format when referring a SRIOV VF
interface without knowing its real interface name.

    sriov:<pf_name>:<vf_id>

You may use this SRIOV VF naming schema for:
 * Top interface name
 * Bond port name
 * Linux bridge port name
 * OVS bridge port name
 * OVS bond port name

Please be advised, we don't support single transaction containing both creating VF and refering VF using above naming format.

Comment 11 Mingyu Shi 2022-11-21 08:48:18 UTC
Created attachment 1926049 [details]
verified.log

Verified with:
nmstate-2.2.1-1.el9.x86_64
NetworkManager-1.41.4-2.el9.x86_64
openvswitch2.15-2.15.0-75.el9fdp.x86_64
DISTRO=RHEL-9.2.0-20221118.4

Comment 13 errata-xmlrpc 2023-05-09 07:31:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nmstate bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2190