Bug 2169685

Summary: guest can still be created after add a tap device to ovs bridge
Product: Red Hat Enterprise Linux 9 Reporter: mhou <mhou>
Component: libvirtAssignee: Virtualization Maintenance <virt-maint>
libvirt sub component: Networking QA Contact: yalzhang <yalzhang>
Status: CLOSED NOTABUG Docs Contact:
Severity: high    
Priority: unspecified CC: kzhang, lmen, tli, virt-maint, yalzhang, yanghliu
Version: 9.2Keywords: Reopened
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-02-15 02:44:55 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 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.