Hide Forgot
Description of problem: When the 'nmcli' command changes a connection configuration the connection name is duplicated, with a new UUID. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install a RHEL7.3 system. 2. List the available nm connections: [root@rhel73 ~]# nmcli con NAME UUID TYPE DEVICE ens3 6b7e7365-af67-4e24-a71b-38a7b02b4684 802-3-ethernet ens3 3. Choose a configuration to change, for example 'ipv4.dhcp-hostname' and check its current value: [root@rhel73 ~]# nmcli con show ens3 | grep dhcp-hostname ipv4.dhcp-hostname: -- ipv6.dhcp-hostname: -- 4. Change the configuration value: [root@rhel73 ~]# nmcli con mod ens3 ipv4.dhcp-hostname `hostname` 5. Check it again: [root@rhel73 ~]# nmcli con show ens3 | grep dhcp-hostname ipv4.dhcp-hostname: rhel73_01733309.vm.jbellomo ipv6.dhcp-hostname: -- 6. List the current nm connections: [root@rhel73 ~]# nmcli con NAME UUID TYPE DEVICE ens3 6b7e7365-af67-4e24-a71b-38a7b02b4684 802-3-ethernet ens3 7. Restart de NetworkManager service: [root@rhel73 ~]# systemctl restart NetworkManager 6. Check the current connection listing: [root@rhel73 ~]# nmcli con Actual results: NAME UUID TYPE DEVICE ens3 0826edf6-36ee-490a-a311-c87fe9b8a0a6 802-3-ethernet ens3 ens3 6b7e7365-af67-4e24-a71b-38a7b02b4684 802-3-ethernet -- Expected results: NAME UUID TYPE DEVICE ens3 6b7e7365-af67-4e24-a71b-38a7b02b4684 802-3-ethernet ens3 Additional info: The original connection received the new configuration value: [root@rhel73 ~]# nmcli con show ens3 | grep "uuid\|dhcp-hostname" connection.uuid: 0826edf6-36ee-490a-a311-c87fe9b8a0a6 ipv4.dhcp-hostname: -- ipv6.dhcp-hostname: -- connection.uuid: 6b7e7365-af67-4e24-a71b-38a7b02b4684 ipv4.dhcp-hostname: rhel73.vm ipv6.dhcp-hostname: rhel73.vm After turned off the vm, I added a new ethernet device to the vm. I turnet on the vm and added it as a new connection: [root@rhel73 ~]# nmcli con add ifname ens8 type ethernet con-name ens8 Connection 'ens8' (fb832859-f896-4d7b-9b2e-01618084850d) successfully added. [root@rhel73 ~]# nmcli con NAME UUID TYPE DEVICE ens3 6b7e7365-af67-4e24-a71b-38a7b02b4684 802-3-ethernet ens3 ens8 fb832859-f896-4d7b-9b2e-01618084850d 802-3-ethernet ens8 I changed the same configuration (ipv4.dhcp-hostname) for to the 'ens8' connection: [root@rhel73 ~]# nmcli con mod ens8 ipv4.dhcp-hostname `hostname` After that the 'nmcli' shows the both connections, 'ens3' and 'ens8' duplicated: [root@rhel73 ~]# nmcli con NAME UUID TYPE DEVICE ens3 61827f5b-99d3-4207-be7a-9f8a6eef5f77 802-3-ethernet ens3 ens8 492a5ee7-af1b-438f-bf42-70cbce868862 802-3-ethernet ens8 ens3 6b7e7365-af67-4e24-a71b-38a7b02b4684 802-3-ethernet -- ens8 fb832859-f896-4d7b-9b2e-01618084850d 802-3-ethernet --
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.