| Summary: | nmcli duplicate a connection name if a configuration is changed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | João Avelino Bellomo Filho <jbellomo> |
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> |
| Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | aloughla, atragler, bgalvani, cww, fgiudici, jbellomo, lrintel, rkhan, sukulkar, thaller |
| Target Milestone: | rc | ||
| 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: | 2016-11-10 14:23:52 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: | |
|
Description
João Avelino Bellomo Filho
2016-11-04 19:13:53 UTC
To summarize, after these steps: - modify dhcp-hostname of connection ens3 - restart of NetworkManager to apply the new parameter you see two different connection ens3. Even if this sounds unexpected, it is exactly how it supposed to work. In order to apply changes to the connection ens3, it should be brought up again with: nmcli connection up ens3 and there is no need to restart NM. When NM is restarted and there is an interface already configured (ens3 in this case), NM will try to keep the interface is its current state. If there is a connection that exactly matches the current state, NM will reuse it and pretend it's active; if there is no matching connection, it will create a new in-memory one and say it's active. In this case the persistent ens3 connection doesn't match because it was manually modified just before restarting NM. This behavior has the goal of avoiding the disruption of network configuration when NM is started. Suppose you are logged into a machine through ssh, NM is not running and you start it. If it simply activated the first persistent connection, it would probably undo the existing configuration and cut the user out. In short, don't restart the whole service only to apply a change to a connection, as this has other potentially bad effects (like bringing down wifi, team and other types of connections). Instead, bring up again only the connection that was modified. We have planned to rework how connections are handled upon restart [1], and the improvement will also solve this case, but for the time being I think NM is working as expected and thus I propose to close this bug. [1] https://bugzilla.gnome.org/show_bug.cgi?id=746440 The customer clarified the issue. I misunderstood their problem. The duplicate connection happens without to set a new dhcp-hostname. If the ifcfg file has an entry related to the dhcp-hostname: [root@rhel72 ~]# grep -i hostname /etc/sysconfig/network-scripts/ifcfg-ens3 DHCP_HOSTNAME=rhel72.vm It is enough to duplicate a connection when the NetworkManager is restarted: [root@rhel72 ~]# nmcli connection NAME UUID TYPE DEVICE ens3 1c59828f-3cd0-4ed0-8345-e67be58a8d62 802-3-ethernet ens3 [root@rhel72 ~]# systemctl restart NetworkManager[root@y32569 ~]# nmcli connection NAME UUID TYPE DEVICE ens3 dc26c631-87f1-4024-9748-71b4cd30e47e 802-3-ethernet ens3 ens3 1c59828f-3cd0-4ed0-8345-e67be58a8d62 802-3-ethernet -- I believe this bug can be closed and I must open a new one with the correct description of the issue. (In reply to João Avelino Bellomo Filho from comment #3) > I believe this bug can be closed and I must open a new one with the correct > description of the issue. Ok, thanks. |