Loading...
Loading...
Description of problem: libvirt should delete the qos set to ovs ports after vm destroyed Version-Release number of selected component (if applicable): libvirt-10.0.0-6.el9_4.x86_64 openvswitch2.17-2.17.0-138.el9fdp.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install openvswitch2.17 on the host, then create a ovs bridge: # /usr/share/openvswitch/scripts/ovs-ctl start /etc/openvswitch/conf.db does not exist ... (warning). Creating empty database /etc/openvswitch/conf.db. Starting ovsdb-server. system ID not configured, please use --system-id ... failed! Configuring Open vSwitch system IDs. Inserting openvswitch module. Starting ovs-vswitchd. Enabling remote OVSDB managers. # ovs-vsctl add-br ovsbr0# ovs-vsctl show b1ae4be1-4deb-420b-bd6c-319806e6cd42 Bridge ovsbr0 Port ovsbr0 Interface ovsbr0 type: internal ovs_version: "2.17.10" 2. Start a vm connected to this bridge with Qos setting: # virsh dumpxml rhel --xpath //interface <interface type="bridge"> <mac address="52:54:00:a9:fb:80"/> <source bridge="ovsbr0"/> <virtualport type="openvswitch"> <parameters interfaceid="798bdd97-bfb8-4e5f-ad67-fa8b44a8d3ee"/> </virtualport> <bandwidth> <inbound average="100" peak="300" burst="500"/> <outbound average="200" peak="400" burst="600"/> </bandwidth> <model type="virtio"/> <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/> </interface> # systemctl restart virtqemud # virsh start rhel Domain 'rhel' started 3. Check the tc rules, all set and expected: [root@localhost ~]# virsh domiflist rhel Interface Type Source Model MAC ----------------------------------------------------------- vnet0 bridge ovsbr0 virtio 52:54:00:a9:fb:80 [root@localhost ~]# tc class show dev vnet0 class htb 1:1 parent 1:fffe prio 0 rate 800Kbit ceil 2400Kbit burst 500Kb cburst 500Kb class htb 1:fffe root rate 2400Kbit ceil 2400Kbit burst 1500b cburst 1500b [root@localhost ~]# tc filter show dev vnet0 parent ffff: filter ingress protocol all pref 1 matchall chain 0 filter ingress protocol all pref 1 matchall chain 0 handle 0x1 not_in_hw action order 1: police 0x3 rate 1600Kbit burst 600Kb mtu 64Kb action drop/continue overhead 0b ref 1 bind 1 Check the rules with ovs-vsctl command, all expected: [root@localhost ~]# ovs-vsctl list qos _uuid : 00a13d7e-e371-4492-af80-904067588354 external_ids : {ifname=vnet0, vm-id="c1070cbb-bdf2-4aaf-8af7-5896d5735095"} other_config : {burst="4096000", max-rate="2400000", min-rate="800000"} queues : {0=889c1e38-ae11-4d8e-aba5-69ce428bdd23} type : linux-htb 4. Destroy the vm, check the qos rules with ovs-vsctl, it still exists, which is unexpected: # virsh destroy rhel Domain 'rhel' destroyed [root@localhost ~]# ovs-vsctl list qos <====== this is unexpected, it should be deleted as vnet0 does not exist any more _uuid : 00a13d7e-e371-4492-af80-904067588354 external_ids : {ifname=vnet0, vm-id="c1070cbb-bdf2-4aaf-8af7-5896d5735095"} other_config : {burst="4096000", max-rate="2400000", min-rate="800000"} queues : {0=889c1e38-ae11-4d8e-aba5-69ce428bdd23} type : linux-htb 5. Restart virtqemud, and start the vm again, it will use the target name as "vnet0" again. Check the rules by tc, it's broken: [root@localhost ~]# systemctl restart virtqemud [root@localhost ~]# virsh start rhel Domain 'rhel' started [root@localhost ~]# tc class show dev vnet0 <======= this is unexpected [root@localhost ~]# tc filter show dev vnet0 parent ffff: filter ingress protocol all pref 1 matchall chain 0 filter ingress protocol all pref 1 matchall chain 0 handle 0x1 not_in_hw action order 1: police 0x1 rate 1600Kbit burst 600Kb mtu 64Kb action drop/continue overhead 0b ref 1 bind 1 Actual results: The ovs qos rule exists even after vm destroyed and vnet* interface deleted Expected results: The ovs qos rules should be deleted after vm destroyed Additional info: When delete/unset the inbound setting, the ovs qos can be deleted successfully. Test on libvirt-8.10.0-1.el9.x86_64 ---> fail, impact rhel 9.2 Test on libvirt-8.0.0-23.module+el8.10.0 ----> pass, so no impact for rhel 8 Test on libvirt-8.5.0-7.3.el9_1.x86_64 ---> fail, impact rhel 9.1
Done-Errata
Red Hat Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.