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 2169685 - guest can still be created after add a tap device to ovs bridge
Summary: guest can still be created after add a tap device to ovs bridge
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libvirt
Version: 9.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-14 10:25 UTC by mhou
Modified: 2023-02-15 02:44 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-02-15 02:44:55 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-148570 0 None None None 2023-02-14 10:25:35 UTC

Description mhou 2023-02-14 10:25:03 UTC
Description of problem:
add a tap device to guest and start failed.

Version-Release number of selected component (if applicable):
kernel version: 5.14.0-265.el9.x86_64
libvirt version: libvirt-9.0.0-3.el9.x86_64
qemu-kvm: qemu-kvm-7.1.0-7.el9.x86_64
ovs version: openvswitch2.17-2.17.0-62.el9fdp.x86_64

How reproducible: 100%


Steps to Reproduce:
1. pre create a tap device
ip tuntap add tap_vnet1 mode tap
nmcli dev set tap_vnet1 managed no
ip link set tap_vnet1 mtu 9200
ip link set tap_vnet1 up

2. add tap_vnet1 to a ovs bridge
ovs-vsctl add-port ovsb1 tap_vnet1
ovs-vsctl list interface tap_vnet1
_uuid               : 626fce11-b0ff-4419-ab82-9cb5aafa8079
admin_state         : up
bfd                 : {}
bfd_status          : {}
cfm_fault           : []
cfm_fault_status    : []
cfm_flap_count      : []
cfm_health          : []
cfm_mpid            : []
cfm_remote_mpids    : []
cfm_remote_opstate  : []
duplex              : full
error               : []
external_ids        : {}
ifindex             : 13
ingress_policing_burst: 0
ingress_policing_kpkts_burst: 0
ingress_policing_kpkts_rate: 0
ingress_policing_rate: 0
lacp_current        : []
link_resets         : 0
link_speed          : 10000000
link_state          : down
lldp                : {}
mac                 : []
mac_in_use          : "42:ab:ef:24:91:76"
mtu                 : 9120
mtu_request         : []
name                : tap_vnet1
ofport              : 6
ofport_request      : []
options             : {}
other_config        : {}
statistics          : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_missed_errors=0, rx_multicast_packets=0, rx_
over_err=0, rx_packets=0, tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
status              : {driver_name=tun, driver_version="1.6", firmware_version=""}
type                : ""


3. define a guest xml that containe tap target.
<interface type='bridge'>
  <mac address='00:de:ad:00:00:01'/>
  <source bridge='ovsbr1'/>
  <virtualport type='openvswitch'/>
  <target dev='tap_vnet1'/>
  <model type='virtio'/>
  <driver name='vhost' iommu='on' ats='on'/>
  <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
</interface>

4. start guest failed
start guest failed with error
error: Failed to create domain from g1.xml
error: Requested operation is not valid: The tap_vnet1 interface already exists

5. use interfaceid to define the tap on guest xml as below:
<interface type='bridge'>
        <mac address='00:de:ad:00:00:01'/>
        <source bridge='ovsbr1'/>
        <virtualport type='openvswitch'>
          <parameters interfaceid='626fce11-b0ff-4419-ab82-9cb5aafa8079'/>
        </virtualport>
        <model type='virtio'/>
        <driver name='vhost' iommu='on' ats='on'/>
        <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </interface>

6. start guest as well

Actual results:
From step 6, start guest as well

Expected results:
From step 6, start guest will failed
Additional info:

Comment 1 yalzhang@redhat.com 2023-02-14 10:42:52 UTC
This is expected result. There was a bug which vm can start even there is a pre-created tap device with the same name(bug 2144738). It was fixed recently.
I think this one should be closed as not a bug.

Comment 2 mhou 2023-02-14 14:58:37 UTC
According to the suggestion of comment1, I modified the description of the bug. Used to track the interfaceid scenario.

Comment 3 mhou 2023-02-15 02:44:55 UTC
Refer to https://bugzilla.redhat.com/show_bug.cgi?id=2144738#c27, this phenomenon is the expected result.


Note You need to log in before you can comment on or make changes to this bug.