1707441 – Boot guest with e1000e, value of "/sys/class/net/$nic/operstate" is wrongly showed as "up" after "(qemu) set_link net0 off"

This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .

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 1707441 - Boot guest with e1000e, value of "/sys/class/net/$nic/operstate" is wrongly showed as "up" after "(qemu) set_link net0 off"

Summary: Boot guest with e1000e, value of "/sys/class/net/$nic/operstate" is wrongly s...

Keywords:
Status:	CLOSED MIGRATED
Alias:	None
Product:	Red Hat Enterprise Linux 9
Classification:	Red Hat
Component:	qemu-kvm
Sub Component:
Version:	unspecified
Hardware:	Unspecified
OS:	Unspecified
Priority:	low
Severity:	low
Target Milestone:	rc
Target Release:	---
Assignee:	Yvugenfi@redhat.com
QA Contact:	Lei Yang
Docs Contact:
URL:
Whiteboard:
Duplicates (1):	1907794 (view as bug list)
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2019-05-07 14:22 UTC by Pei Zhang
Modified:	2023-08-14 01:33 UTC (History)
CC List:	15 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2023-08-14 01:33:39 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	RHEL-1218	0	None	None	None	2023-08-14 01:33:38 UTC

Description Pei Zhang 2019-05-07 14:22:55 UTC

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 \

Comment 2 jason wang 2019-05-13 08:56:10 UTC

Corner case. Lower the priority and severity.

Thanks

Comment 3 Yihuang Yu 2019-05-16 03:28:28 UTC

Hi Pei,

Please see BZ 1641656

Comment 4 Pei Zhang 2019-05-16 07:57:25 UTC

(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

Comment 6 Ademar Reis 2020-02-05 22:57:04 UTC

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

Comment 7 Bernie Hoefer 2020-08-08 20:37:31 UTC

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.)

Comment 8 Yvugenfi@redhat.com 2020-08-09 07:16:55 UTC

(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

Comment 9 Bernie Hoefer 2020-08-10 15:09:47 UTC

(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!

Comment 12 Lei Yang 2020-12-02 00:43:23 UTC

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

Comment 14 Lei Yang 2021-01-05 05:20:15 UTC

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

Comment 15 Yvugenfi@redhat.com 2021-01-05 11:02:31 UTC

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.

Comment 16 Yvugenfi@redhat.com 2021-01-05 11:12:39 UTC

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.

Comment 17 Lei Yang 2021-01-06 07:32:41 UTC

(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".

Comment 18 Balazs Nemeth 2021-01-22 12:08:05 UTC

*** Bug 1907794 has been marked as a duplicate of this bug. ***

Comment 19 Lei Yang 2021-05-31 13:08:56 UTC

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

Comment 20 Yvugenfi@redhat.com 2021-05-31 13:20:56 UTC

(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.

Comment 28 John Ferlan 2021-09-14 22:43:26 UTC

Bulk update: Move RHEL8 bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Comment 30 RHEL Program Management 2021-11-23 07:27:10 UTC

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.

Comment 31 Lei Yang 2021-11-23 12:57:43 UTC

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

Comment 33 Lei Yang 2022-01-10 02:31:34 UTC

Hit same issue

Test Version:
qemu-kvm-6.2.0-1.el9.x86_64
kernel-5.14.0-39.el9.x86_64

Comment 34 yalzhang@redhat.com 2022-01-18 01:13:29 UTC

Please be noted that e1000e will be introduced in ovirt-engine 4.7, rhel 8.6.0+, see Bug 2033185.

Comment 36 Lei Yang 2022-04-25 05:24:49 UTC

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

Comment 37 Yvugenfi@redhat.com 2022-04-25 06:03:49 UTC

(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

Comment 38 Bernie Hoefer 2022-04-25 12:43:07 UTC

(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.

Comment 39 Yvugenfi@redhat.com 2022-04-25 12:46:59 UTC

(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.

Comment 40 Bernie Hoefer 2022-04-25 12:53:30 UTC

(In reply to Yvugenfi from comment #39)
===
> I prefer to keep it open.
===

Wonderful; thank you!

Comment 41 RHEL Program Management 2022-11-10 07:27:58 UTC

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.

Comment 42 Yvugenfi@redhat.com 2022-11-10 07:45:04 UTC

Upstream work continues.

Comment 43 Lei Yang 2022-12-26 06:11:17 UTC

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

Comment 45 Lei Yang 2023-05-11 05:21:49 UTC

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

Comment 46 Akihiko Odaki 2023-07-10 15:58:33 UTC

The fix is merged upstream: https://gitlab.com/qemu-project/qemu/-/commit/e414270000e9f7fe2a56d314ab85259aeaf1bd91

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