#3179 PR open: Migrate MAC addresses and interface names in NetworkManager keyfiles during network configuration migration

Labels: enhancement

pcahyna opened issue at 2024-03-14 08:07:

Pull Request Details:

  • Type: Enhancement

  • Impact: Normal

  • Reference to related issue (URL):

  • How was this pull request tested?
    Migration of Fedora Linux system to different hardware (different NICs). With this patch, the network connections are preserved and functional after recovery, even though the NICs have different names and different MAC adresses.

  • Description of the changes in this pull request:
    Migrate NM keyfiles during network conf migration. See https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/ for more details on NetworkManager keyfiles.
    Only MAC addresses and interface names are migrated for now.
    TODO: migrate also IP addresses and routes.

pcahyna commented at 2024-03-14 22:33:

Regarding "TODO: migrate also IP addresses and routes."

Is it worth supporting migration of IP addresses and routes? What is the use case? I suppose it is for machine cloning to several not completely identical (different network address) copies, as I don't see how it is useful for the typical use of ReaR (disaster and recovery) where you need an identical address after recovery. Would it be acceptable to remove this feature (say in ReaR 3.0)?

jsmeix commented at 2024-03-15 07:36:

@pcahyna
offhandedly I don't know what the use case is
for migration of IP addresses and routes.

My guess is similar as yours that at some time in the past
someone (mis?)used ReaR for migration of networking setup?

Perhaps (also only a guess) the idea behind is to use ReaR
to migrate a system from one environment into a different
environment, for example from bare metal hardware in one
network environment to a VM in another network environment
or something like that?

On the one hand ReaR has too many (often half-baked) features
that are almost never used in practice (and bit-rotting)
so I would like to drop corner-case features that are not
sufficiently well implemented and basically unmaintained
at ReaR upstream because it is a nightmare to maintain
when customers have issues with such features.

On the other hand such features can be a starting point for
further development to get them sufficiently well implemented
so such features could become business opportunities when
customers want to pay for further development.

I think the solution out of this conflict is
deprecation via ErrorIfDeprecated().

This way we learn via somewhat enforced user feedback
which of those features are actually in use and
we can ask back those users what their use-case is
so we better understand those corner-case features
and then we can make an informed decision
what to do with each individual corner-case feature
(drop it, keep it as is, further develop it).

jsmeix commented at 2024-03-15 07:58:

@pcahyna
could you by the way show $network_config_file values
in user output messages with ' to make it clear
when a single value consists of more than one word.

As far as I see it is those two code places

Log "Wrote new MAC addresses and network interfaces in $network_config_file"
...
LogPrintError "Failed to rewrite MAC addresses and network interfaces in $network_config_file"

that should be enhanced to

Log "Wrote new MAC addresses and network interfaces in '$network_config_file'"
...
LogPrintError "Failed to rewrite MAC addresses and network interfaces in '$network_config_file'"

pcahyna commented at 2024-03-15 13:58:

My guess is similar as yours that at some time in the past someone (mis?)used ReaR for migration of networking setup?

Perhaps (also only a guess) the idea behind is to use ReaR to migrate a system from one environment into a different environment, for example from bare metal hardware in one network environment to a VM in another network environment or something like that?

I supposed the idea was to use ReaR for cloning, i.e. backup a machine once and then restore it to multiple instances, each one will then need a different IP address. It seems though that according to the commit message of 844d50b75ac4b7722f4fee7a5ee3350b93f3adb7 by @schlomo where this functionality was introduced, they had indeed rather the idea of "migrating bare metal hardware in one network environment to a VM in another network environment" in mind.

schlomo commented at 2024-03-15 14:11:

Oh yes, that was the first version of migration support developed for P2V.

pcahyna commented at 2024-03-15 16:39:

@pcahyna could you by the way show $network_config_file values in user output messages with ' to make it clear when a single value consists of more than one word.

As far as I see it is those two code places

Log "Wrote new MAC addresses and network interfaces in $network_config_file"
...
LogPrintError "Failed to rewrite MAC addresses and network interfaces in $network_config_file"

that should be enhanced to

Log "Wrote new MAC addresses and network interfaces in '$network_config_file'"
...
LogPrintError "Failed to rewrite MAC addresses and network interfaces in '$network_config_file'"

@jsmeix sure, 5ea58a7f91d80aa2dbe4da16802ab2a8c46b28a5

pcahyna commented at 2024-03-15 16:41:

I now pushed another change, 5ea58a7f91d80aa2dbe4da16802ab2a8c46b28a5, for a proper test for an empty array. Unfortunately, the code is now untested, as I have not tested with this change.

[Export of Github issue for rear/rear.]