GNOME Bugzilla – Bug 697370
live reconfiguration of NMDevices
Last modified: 2016-02-23 11:00:49 UTC
We want to be able to reconfigure devices without taking them down. The simplest way to do this is to allow updating an active NMConnection, and propagating the changes from the connection definition to the device. In some cases we will want to be able to make non-persistent changes to the device, which in this model means making non-persistent changes to the connection. Initial work for this is (barely) started on danw/live-reconfig, and will be worked on more later
So, looking at the various settings properties... The majority of properties are non-live-reconfigurable, because of one or more of: - they are only relevant when the device is first connecting - the driver doesn't let you change them while the device is up - they are managed by an external process - changing them implies that the connection would become something totally different These are: 8021x:* Adsl:* Bluetooth:type Cdma:* Connection:master Connection:slave-type Connection:type Gsm:* IP4Config:dhcp-client-id IP4Config:dhcp-send-hostname IP4Config:dhcp-hostname IP4Config:method IP6Config:dhcp-hostname IP6Config:method OlpcMesh:* PPP:* PPPOE:* Vlan:id Vlan:parent Vpn:* Wimax:network-name Wireless:band Wireless:bssid Wireless:channel Wireless:hidden Wireless:mode Wireless:rate Wireless:security Wireless:ssid WirelessSecurity:* Does this mean that we ignore changes to them, or that we bounce the device on changes to them? I'm thinking maybe we don't want this to be fully auto-apply, but rather we should have a Reconfigure method, and then in that case, when you call it, we bounce the device if we need to (possibly with a warning first?). Technically Connection:secondaries goes on this list too, but that's much easier than the others to fake without actually taking the device down (though we might not want to bother). Properties that only affect NM-internal bookkeeping: Connection:autoconnect Connection:id Connection:permissions (?) Connection:read-only Connection:timestamp Connection:uuid Connection:zone Properties that affect whether the connection matches the device, meaning that changing them will either be a no-op, or will cause the connection to be deactivated: Bluetooth:bdaddr Connection:interface-name Infiniband:mac-address Wimax:mac-address Wired:mac-address Wired:mac-address-blacklist Wired:s390-subchannels Wireless:mac-address Wireless:mac-address-blacklist and similarly but slightly differently: IP4Config:may-fail IP6Config:may-fail Properties that affect non-device-type-specific things, that can be reconfigured while the device is up: BridgePort:* Ip[46]Config:addresses Ip[46]Config:dns Ip[46]Config:dns-search Ip[46]Config:ignore-auto-dns Ip[46]Config:ignore-auto-routes Ip[46]Config:never-default Ip[46]Config:routes Ip6Config:ip6-privacy Properties that affect device-type-specific things, that can be reconfigured while the device is up: Bond:* Bridge:* Infiniband:mtu Infiniband:transport-mode Vlan:egress-priority-map Vlan:ingress-priority-map Vlan:interface-name Vlan:flags Wired:mtu Wired:cloned-mac-address Wireless:mtu Wireless:cloned-mac-address
Looks reasonable. If the framework is there, we can start fixing individual non-reconfigurable options, too.
pushed some work to danw/live-reconfig. I'm going to hold off until Pavel is done with the NMDevice->NMConnection work before finishing, since otherwise there will be conflicts everywhere.
(In reply to comment #3) > pushed some work to danw/live-reconfig. I'm going to hold off until Pavel is > done with the NMDevice->NMConnection work before finishing, since otherwise > there will be conflicts everywhere. Thanks for considering the conflicts. Just went through your branch and it looks like the conflicts shouldn't be serious this time, if any. I realized there will be a bit more work on pavlix/runtime regarding NMIP[46]Config because of the DHCP stuff. I'm going to deliver the code for review on thursday next week (friday is a national holiday) but it won'd be immediately ready for merge. Also I see you are improving the comparison mechanisms for NMConnection objects, which may be necessary to operate properly after pavlix/platform patches are applied, because... for (iter = connections; iter; iter = iter->next) { NMConnection *candidate = NM_CONNECTION (iter->data); if (nm_connection_compare (candidate, connection, NM_SETTING_COMPARE_FLAG_FUZZY)) { nm_log_dbg (LOGD_DEVICE, "(%s): found matching connection '%s'", nm_device_get_iface (device), nm_connection_get_id (connection)); g_object_unref (connection); connection = candidate; break; } } If in doubt, please see bug 703311 and the pavlix/runtime branch.
(In reply to comment #4) > Thanks for considering the conflicts. Just went through your branch and it > looks like the conflicts shouldn't be serious this time, if any. I realized > there will be a bit more work on pavlix/runtime regarding NMIP[46]Config > because of the DHCP stuff. Yeah, it was mostly the IP stuff (which isn't done yet on danw/live-reconfig) that looked like it was going to be conflicting. > Also I see you are improving the comparison mechanisms for NMConnection > objects, which may be necessary to operate properly after pavlix/platform > patches are applied Feel free to cherry-pick those patches. Updates to my earlier list of properties: (In reply to comment #1) > The majority of properties are non-live-reconfigurable, because of one or more > of: > > - they are only relevant when the device is first connecting Add Connection:gateway-ping-timeout to this list > Properties that affect non-device-type-specific things, that can be > reconfigured while the device is up: > Ip6Config:ip6-privacy that should have been in the not-live-reconfigurable list, since changing it will probably change your primary IP address and break all of your TCP connections. > Properties that affect device-type-specific things, that can be reconfigured > while the device is up: > > Bond:* Not actually true, according to the code (it's possible that some properties can be live-reconfigured (eg, miimon) and others can't (eg, mode)). > Wired:cloned-mac-address > Wireless:cloned-mac-address Likewise, these can't be changed while the device is up.
I think the list you've got is pretty much correct. I wonder if we should add some code to libnm-util that would indicate in a generic way whether or not changing a property will have an immediate effect or not? That might prevent code duplication between UIs (nmcli, shell, cc, etc).
Downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1032717
Depends on bug 724041.
Effectively, bug 724041 and bug 758463 mostly implements what is requested here. What works: - D-Bus API Reapply() and GetAppliedConnection() - $ nmcli device reapply $DEV command to update the device configuration with an updated modify- connection. What doesn't work yet: - currently you can only reapply * connection.firewall-zone * connection.metered * ipv4.* * ipv6.* danw/live-reconfig was implementing more properties that can be reapplied. - need more UI support: $ nmcli connection modify --reapply $CON +ipv4.addresses 192.168.0.5/24 $ nmcli device modify $DEV +ipv4.addresses 192.168.0.5/24
Created attachment 321936 [details] [review] [patch] danw/live-reconfig This is the branch danw/live-reconfig, it applies on commit ec1376fad23dfc19472809191d0e56cbd9c0d2b2. The branch contains some good stuff, but is obsolete and will not apply at all. >> platform: split nm_platform_vlan_set_flags() out of nm_platform_vlan_add() Fixed differently by: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a5ea141956eea99f0882061d12d229d36c9ea684 >> live-reconfig [wip] priv->current_connection became applied_connection and reconfigure() is reapply_connection().
(In reply to Thomas Haller from comment #9) > What doesn't work yet: > > - currently you can only reapply > * connection.firewall-zone > * connection.metered > * ipv4.* > * ipv6.* > danw/live-reconfig was implementing more properties that can be > reapplied. > > - need more UI support: > $ nmcli connection modify --reapply $CON +ipv4.addresses 192.168.0.5/24 > $ nmcli device modify $DEV +ipv4.addresses 192.168.0.5/24 I'm closing this bug, let's open more specific bugs for the remaining features.