Bug 1707441
| Summary: | Boot guest with e1000e, value of "/sys/class/net/$nic/operstate" is wrongly showed as "up" after "(qemu) set_link net0 off" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Pei Zhang <pezhang> |
| Component: | qemu-kvm | Assignee: | Yvugenfi <yvugenfi> |
| qemu-kvm sub component: | Networking | QA Contact: | Lei Yang <leiyang> |
| Status: | CLOSED MIGRATED | Docs Contact: | |
| Severity: | low | ||
| Priority: | low | CC: | aadam, aodaki, bhoefer, chayang, jinzhao, juzhang, lvivier, mdean, rbalakri, rkhan, virt-maint, yalzhang, ybendito, yihyu, yvugenfi |
| Version: | unspecified | Keywords: | MigratedToJIRA, Reopened, 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-08-14 01:33:39 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: | |||
Corner case. Lower the priority and severity. Thanks Hi Pei, Please see BZ 1641656 (In reply to Yihuang Yu from comment #3) > Hi Pei, > > Please see BZ 1641656 Hi Yihuang, There is difference between these 2 bugs. For this bug, qemu doesn't set "status=", so it means it's using default value. This bug is reported because "(qemu) set_link" doesn't show the correct nic status in guest, this may confuse users. But I also agree with Jason that this is a corner case. Thanks, Pei QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks I hit this bug while running at test, today, using Windows 10 Enterprise LTSC in a virtual machine containing a e1000e virtual NIC. I found my way to this Bugzilla ticket via [https://bugs.launchpad.net/qemu/+bug/1857226]. (Actually, I hit the bug while using virt-manager on Fedora 31. Unchecking the virtual machine's "Link status" box had no effect. I don't see the point in opening a Bugzilla ticket under the Fedora product since the issue is already being worked here and any developed fix will be sent upstream and thus eventually make its way into Fedora. But, I'd be happy to make a Fedora Bugzilla ticket if that is desirable.) (In reply to Bernie Hoefer from comment #7) > I hit this bug while running at test, today, using Windows 10 Enterprise > LTSC in a virtual machine containing a e1000e virtual NIC. I found my way > to this Bugzilla ticket via [https://bugs.launchpad.net/qemu/+bug/1857226]. > > (Actually, I hit the bug while using virt-manager on Fedora 31. Unchecking > the virtual machine's "Link status" box had no effect. I don't see the > point in opening a Bugzilla ticket under the Fedora product since the issue > is already being worked here and any developed fix will be sent upstream and > thus eventually make its way into Fedora. But, I'd be happy to make a > Fedora Bugzilla ticket if that is desirable.) Thanks, but I don't think there is a need to open another ticket for Fedora. The patches will be submitted first to QEMU upstream anyway. So Fedora will get them with the update of QEMU. There is still a discussion what exact changes should be done: https://www.mail-archive.com/qemu-devel@nongnu.org/msg700969.html (In reply to Yan Vugenfirer from comment #8) > Thanks, but I don't think there is a need to open another ticket for Fedora. > The patches will be submitted first to QEMU upstream anyway. So Fedora will > get them with the update of QEMU. Acknowledged. > There is still a discussion what exact changes should be done: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg700969.html Thanks! Hit this issue with RHEL.8.4.0_guest + e1000e device Test Version: qemu-kvm-5.2.0-0.scrmod+el8.4.0+8862+2dc743cb.wrb201125.x86_64 kernel-4.18.0-252.el8.x86_64 Hi, Yan According to comment 13,I have some questions to confirm with you: 1.Do we have plans to fix this bug on RHEL.8.4? If it will be fixed on RHEL.8.4, can I temporarily set it to ITM16？ 2.Or the stale date should be reset ? Best regards Lei Yang Hi Lei Yang, The patches were not accepted yet upstream. I don't think the fixes will make it to RHEL8.4. Let's reset the date. Best regards, Yan. Hi Lei Yang, The patches were not accepted yet upstream. I don't think the fixes will make it to RHEL8.4. Let's reset the date. Best regards, Yan. (In reply to Yan Vugenfirer from comment #16) > Hi Lei Yang, > > The patches were not accepted yet upstream. I don't think the fixes will > make it to RHEL8.4. > Let's reset the date. > > Best regards, > Yan. Thanks Yan, based on above reset "stale date". *** Bug 1907794 has been marked as a duplicate of this bug. *** Hit same issue when run e1000e funtion test on rhel9-beat host. Guest: rhel8.5 Test Version: qemu-kvm-6.0.0-3.el9.x86_64 kernel-5.13.0-0.rc2.19.el9.x86_64 (In reply to Lei Yang from comment #19) > Hit same issue when run e1000e funtion test on rhel9-beat host. > > Guest: rhel8.5 > Test Version: > qemu-kvm-6.0.0-3.el9.x86_64 > kernel-5.13.0-0.rc2.19.el9.x86_64 The changes are not accepted to upstream QEMU yet. Bulk update: Move RHEL8 bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. The same problem still exists in rhel9.0.0, So re-open it. Test Version: qemu-kvm-6.1.0-6.el9.x86_64 kernel-5.14.0-9.el9.x86_64 Hit same issue Test Version: qemu-kvm-6.2.0-1.el9.x86_64 kernel-5.14.0-39.el9.x86_64 Please be noted that e1000e will be introduced in ovirt-engine 4.7, rhel 8.6.0+, see Bug 2033185. Hit same issue Test Version: qemu-kvm-6.2.0-9.module+el8.7.0+14737+6552dcb8.x86_64 kernel-4.18.0-384.el8.x86_64 (In reply to Lei Yang from comment #36) > Hit same issue > > Test Version: > qemu-kvm-6.2.0-9.module+el8.7.0+14737+6552dcb8.x86_64 > kernel-4.18.0-384.el8.x86_64 Yes, the fix is still not upstream (In reply to Yvugenfi from comment #37) === > Yes, the fix is still not upstream === Yan, will this Bugzilla ticket remain open until a fix is available in the upstream project? I ask, because of the auto-close warning received on 2022-04-23. Thank you. (In reply to Bernie Hoefer from comment #38) > (In reply to Yvugenfi from comment #37) > === > > Yes, the fix is still not upstream > === > > Yan, will this Bugzilla ticket remain open until a fix is available in the > upstream project? I ask, because of the auto-close warning received on > 2022-04-23. Thank you. Hi Bernie, I prefer to keep it open. (In reply to Yvugenfi from comment #39) === > I prefer to keep it open. === Wonderful; thank you! After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. Upstream work continues. Hit same issue Test Version: kernel-5.14.0-226.el9.x86_64 qemu-kvm-7.2.0-2.el9.x86_64 edk2-ovmf-20221207gitfff6d81270b5-1.el9.noarch Hit same issue Test Version: kernel-5.14.0-307.el9.x86_64 qemu-kvm-8.0.0-1.el9.x86_64 edk2-ovmf-20230301gitf80f052277c8-2.el9.noarch The fix is merged upstream: https://gitlab.com/qemu-project/qemu/-/commit/e414270000e9f7fe2a56d314ab85259aeaf1bd91 |
Description of problem: Boot guest with e1000e. After executing "(qemu) set_link net0 off", the value of "/sys/class/net/$nic/operstate" in guest is 'up'. but the expected value is 'down'. Version-Release number of selected component (if applicable): 4.18.0-82.el8.x86_64 qemu-kvm-2.12.0-69.module+el8.1.0+3143+457f984c.x86_64 How reproducible: 100% Steps to Reproduce: 1. Boot guest with e1000e -netdev tap,id=hostnet0 \ -device e1000e,netdev=hostnet0,id=net0,mac=fa:5e:07:b4:08:01,bus=root.2 \ 2. In qemu terminal, set this NIC link off (qemu) set_link net0 off 3. In guest, check status, it's wrongly showed "up". # ifconfig ens2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.73.74.39 netmask 255.255.252.0 broadcast 10.73.75.255 inet6 fe80::f85e:7ff:feb4:801 prefixlen 64 scopeid 0x20<link> ether fa:5e:07:b4:08:01 txqueuelen 1000 (Ethernet) RX packets 81602 bytes 6158528 (5.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 268 bytes 758903 (741.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 23 memory 0xfe640000-fe660000 # cat /sys/class/net/ens2/operstate up Actual results: The value of /sys/class/net/$nic/operstate is wrongly showed "up" after set link down. Expected results: The value of /sys/class/net/$nic/operstate should be showed "down" after set link down. Additional info: 1. virtio-net-pci works well. So it's only e1000e issue. Reference: 1. Full cmd line: /usr/libexec/qemu-kvm -name rhel8.0 \ -M q35,kernel-irqchip=split \ -cpu host -m 8G \ -smp 4,sockets=1,cores=4,threads=1 \ -device pcie-root-port,id=root.1,slot=1 \ -device pcie-root-port,id=root.2,slot=2 \ -drive file=/home/rhel8.0.qcow2,format=qcow2,if=none,id=drive-virtio-blk0,werror=stop,rerror=stop \ -device virtio-blk-pci,drive=drive-virtio-blk0,id=virtio-blk0,bus=root.1 \ -vnc :2 \ -monitor stdio \ -netdev tap,id=hostnet0 \ -device e1000e,netdev=hostnet0,id=net0,mac=fa:5e:07:b4:08:01,bus=root.2 \