Bug 1915284
| Summary: | veth device profiles activation is not reboot persistent | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Vladimir Benes <vbenes> |
| Component: | NetworkManager | Assignee: | Fernando F. Mancera <ferferna> |
| Status: | CLOSED DUPLICATE | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.3 | CC: | acardace, bgalvani, ferferna, fge, jiehuang, lrintel, rkhan, sfaye, sukulkar, thaller, till, welin |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-10-18 05:33:54 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: | |||
Fernando, what is your opinion about this report? I agree with Vladimir. This should be reboot persistent.. I don't know what is happening but this is a legit bug. > after system booted up: > [root@gsm-r5s10-01 ~]# nmcli device > DEVICE TYPE STATE CONNECTION > eth0 ethernet connected testeth0 > test12 ethernet connected test12+ > lo loopback unmanaged -- where is test11? > nmcli connection add type veth con-name test11+ ifname test11 veth.peer test12 ip4 10.42.0.2 > nmcli connection add type veth con-name test12+ ifname test12 veth.peer test11 ip4 10.42.0.1 A veth profile creates two peers (`ifname test11` and `veth.peer test12`) and on the first peer it does IP configuration. By default, the other peer will be marked as unmanaged by a udev rule. So the second profile cannot autoconnect. That seems right. If I disable that udev rule, the it actually works and the second profile also autoactivates as desired. One thing seems wrong however: a veth profile can also activate on an existing interface. Question: should the veth profile activate on a device that is no veth (eg. plain ethernet)? Should the veth be allowed to activate on a veth device that has a differently named peer? Should the veth device be allowed to activate on a veth device whose peer is invisible (because it got moved to another namespace)? 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. hello, I have meet this issue on RHEL 8.6, have any solution for this issue?
# hostnamectl
Static hostname: ip-192-168-4-10.us-east-2.compute.internal
Icon name: computer-vm
Chassis: vm
Machine ID: a63bb499444c40348efbe29996231d04
Boot ID: 70a8d643fe814b8da1f80ffa2ddc7d51
Virtualization: xen
Operating System: Red Hat Enterprise Linux 8.6 (Ootpa)
CPE OS Name: cpe:/o:redhat:enterprise_linux:8::baseos
Kernel: Linux 4.18.0-372.9.1.el8.x86_64
Architecture: x86-64
# nmcli connection add type veth con-name test11+ ifname test11 veth.peer test12 ip4 10.42.0.2
# nmcli connection add type veth con-name test12+ ifname test12 veth.peer test11 ip4 10.42.0.1
# nmcli con up test11+
# nmcli con up test12+
# nmcli con show
NAME UUID TYPE DEVICE
System eth0 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 ethernet eth0
test11+ 442ab16a-ee78-4bff-b008-b95b9b260704 veth test11
test12+ e066f496-61c0-451d-8f91-5fef3384aa58 veth test12
# reboot
# nmcli con show
NAME UUID TYPE DEVICE
System eth0 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 ethernet eth0
test12+ e066f496-61c0-451d-8f91-5fef3384aa58 veth test12
test11+ 442ab16a-ee78-4bff-b008-b95b9b260704 veth --
# nmcli dev
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected System eth0
br-vlan33 bridge connected br-vlan33
test12 ethernet connected test12+
br-trunk bridge connected br-trunk
br-vlan32 bridge connected br-vlan32
docker0 bridge connected (externally) docker0
virbr0 bridge connected (externally) virbr0
eth0.33 vlan connected eth0.33
lo loopback unmanaged --
ovs-system openvswitch unmanaged --
ovsbr-1 openvswitch unmanaged --
after reboot, the veth test11+ has lost, does it a BUG?
|
Description of problem: Having two devices nmcli connection add type veth con-name test11+ ifname test11 veth.peer test12 ip4 10.42.0.2 nmcli connection add type veth con-name test12+ ifname test12 veth.peer test11 ip4 10.42.0.1 nmcli con up test12+ reboot after system booted up: [root@gsm-r5s10-01 ~]# nmcli device DEVICE TYPE STATE CONNECTION eth0 ethernet connected testeth0 test12 ethernet connected test12+ lo loopback unmanaged -- [root@gsm-r5s10-01 ~]# nmcli connection NAME UUID TYPE DEVICE testeth0 73314713-4c70-4cc8-badd-d7aa8a99b84a ethernet eth0 test12+ 1fec96c0-99cf-4b64-9366-847b514d208a veth test12 test11+ cabdae80-1181-4e7c-b75b-3a9c7a46a9d4 veth -- [root@gsm-r5s10-01 ~]# ip a s 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 50:7b:9d:d8:30:fe brd ff:ff:ff:ff:ff:ff inet 10.16.122.98/24 brd 10.16.122.255 scope global dynamic noprefixroute eth0 valid_lft 86369sec preferred_lft 86369sec inet6 2620:52:0:107a:527b:9dff:fed8:30fe/64 scope global dynamic noprefixroute valid_lft 2591988sec preferred_lft 604788sec inet6 fe80::527b:9dff:fed8:30fe/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: test11@test12: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ae:a5:75:3f:65:53 brd ff:ff:ff:ff:ff:ff 4: test12@test11: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 link/ether 32:79:50:48:0e:99 brd ff:ff:ff:ff:ff:ff inet 10.42.0.1/32 scope global noprefixroute test12 valid_lft forever preferred_lft forever inet6 fe80::7e0e:ffef:9d3:4197/64 scope link tentative noprefixroute valid_lft forever preferred_lft forever this looks incorrect. Why test12+? One would expect test11+ as it should create the pair, but probably activation time is after test12+. We need a different approach here. Version-Release number of selected component (if applicable): 1.30.0-5