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 2035726

Summary:	Live update to delete the vlan tag on the interface fail
Product:	Red Hat Enterprise Linux 9	Reporter:	yalzhang <yalzhang>
Component:	libvirt	Assignee:	Laine Stump <laine>
libvirt sub component:	Networking	QA Contact:	yalzhang <yalzhang>
Status:	CLOSED MIGRATED	Docs Contact:
Severity:	low
Priority:	unspecified	CC:	aadam, jsuchane, lvivier, virt-maint
Version:	9.0	Keywords:	MigratedToJIRA, Triaged
Target Milestone:	rc	Flags:	pm-rhel: mirror+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-22 15:51:51 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:

Description yalzhang@redhat.com 2021-12-27 09:12:04 UTC

Description of problem:
Live update to delete the vlan tag on the interface fail

Version-Release number of selected component (if applicable):
libvirt-7.10.0-1.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1.  Start vm with interface as below with vlan tag defined:
 # virsh dumpxml rhel9 | grep /interface -B10
    <interface type='bridge'>
      <mac address='52:54:00:da:b9:fb'/>
      <source bridge='ovsbr0'/>
      <virtualport type='openvswitch'>
        <parameters interfaceid='67f7ce64-6ca9-4bb1-9309-f244a4e12213'/>
      </virtualport>
      <target dev='vnet39'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </interface>

2. Live add vlan tag, succeed
# cat  bridge_vlan.xml
  <interface type='bridge'>
      <mac address='52:54:00:da:b9:fb'/>
      <source bridge='ovsbr0'/>
      <virtualport type='openvswitch'>
        <parameters interfaceid='67f7ce64-6ca9-4bb1-9309-f244a4e12213'/>
      </virtualport>
      <target dev='vnet39'/>
      <vlan>
        <tag id='45'/>
      </vlan>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </interface>
# virsh update-device rhel9 bridge_vlan.xml
Device updated successfully

# virsh dumpxml rhel9 | grep /interface -B13
    <interface type='bridge'>
      <mac address='52:54:00:da:b9:fb'/>
      <source bridge='ovsbr0'/>
      <vlan>
        <tag id='45'/>
      </vlan>
      <virtualport type='openvswitch'>
        <parameters interfaceid='67f7ce64-6ca9-4bb1-9309-f244a4e12213'/>
      </virtualport>
      <target dev='vnet39'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </interface>
# ovs-vsctl show
0415a226-8ac6-4721-a812-1f9d5754f969
    Bridge ovsbr0
        Port ovsbr0
            Interface ovsbr0
                type: internal
        Port vnet39
            tag: 45
            Interface vnet39
    ovs_version: "2.15.3"

3. Live delete the vlan tag, fail:
# cat bridge_del_vlan.xml
  <interface type='bridge'>
      <mac address='52:54:00:da:b9:fb'/>
      <source bridge='ovsbr0'/>
      <virtualport type='openvswitch'>
        <parameters interfaceid='67f7ce64-6ca9-4bb1-9309-f244a4e12213'/>
      </virtualport>
      <target dev='vnet39'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </interface>

# virsh update-device rhel9 bridge_del_vlan.xml
error: Failed to update device from bridge_del_vlan.xml
error: internal error: Unable to set vlan configuration on port vnet39

Actual results:
VLAN tag can be added or value updated by update-device lively, but can not be deleted.

Expected results:
Step 3 should succeed

Additional info:
Network connections that support guest-transparent VLAN tagging include:
1) type='bridge' interfaces connected to an Open vSwitch bridge;
2) SRIOV Virtual Functions (VF) used via type='hostdev' (direct device assignment);
3) SRIOV VFs used via type='direct' with mode='passthrough' (macvtap "passthru" mode)
For 2), hostdev interface do not support live update;
For 1) and 3), the behavior is the same, vlan tag can be added or value updated by update-device lively, but can not be deleted.

Comment 4 Jaroslav Suchanek 2022-01-27 15:48:40 UTC

Laine, would you please have a look. Thanks.

Comment 5 Laine Stump 2022-02-03 15:20:51 UTC

I don't think anybody ever considered that "-1" could/would be used to reset the vlan tag of an interface to 0. I'm not sure where you got the idea that should work.

As for doing a live update of the vlan tag on an SRIOV hostdev or direct (macvtap passthrough mode) interface:

hostdev: no changes to an SRIOV hostdev interface are supported by update-device, so any difference at all (including a difference in the vlan tag) will result in an error.

direct (macvtap) passthrough: Support for live update of a vlan tag was added by commit e484cb3ecaa in 2017, but only for OVS ports; it didn't do anything for SRIOV interfaces, but because of the way the patch was written, it removed the check that would have triggered an error, so no "unsupported" error is reported, but then the code goes ahead and calls an OVS-specific function to try and update the vlan tag of an interface that is *not* an OVS interface. I haven't tried it, but according to your report, this attempt apparently silently fails. So the status XML for the interface is updated, but if you look at the output of "ip link show" of the PF, it will show that the VF's vlan tag has not changed.

So there are a couple of different bugs here:

1) the inability to set vlan tag of an existing interface back to 0.

2) when a live update of a direct/passthrough interface changes the vlan, it silently fails while appearing to succeed.

Issue (1) has brought up a larger problem - the difference between "leave the vlan tag alone" and "set the vlan tag to 0 / clear the vlan tag"). Looking back on the code, it seems like this is a bit of a mess - both of these were represented by just not specifying a <vlan> element at all, and behavior is different between OVS and SRIOV macvtap devices. I don't really like the idea of using "-1" for either "leave along" or "set to 0". It's been several years since I looked at or even thought about this code, so I need to spend some time experimenting and thinking about what would be the best way to solve this ambiguity while maintaining backwards compatibility.

Comment 7 RHEL Program Management 2023-09-22 15:51:19 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 8 RHEL Program Management 2023-09-22 15:51:51 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.