#2049 PR merged: add eno-fix.rules to the RULE_FILES array #2046

Labels: enhancement, fixed / solved / done

gdha opened issue at 2019-02-20 07:01:

Signed-off-by: Gratien D'haese gratien.dhaese@gmail.com

  • Type: Enhancement

  • Impact: Low

  • Reference to related issue (URL): #2046

  • How was this pull request tested? at the customer site with success

  • Brief description of the changes in this pull request: See #2046 for the full problem description.

What we found is that Red Hat Enterprise Linux 7 virtual guests using the vmxnet3 driver on VMware hypervisors have names such as eno16780032 instead of an expected name such as ens192 (scheme 2). Unfortunately, this can lead to not only inconsistent network device names but sometimes network loss when the virtual guest machine or the hypervisor was rebooted.

jsmeix commented at 2019-02-20 10:23:

@gdha
while you are at it I would like to suggest to replace in
usr/share/rear/finalize/GNU/Linux/310_migrate_udev_rules.sh

cp $v "$rule" $TARGET_FS_ROOT/"$rule" >&2
StopIfError "Could not copy '$rule' -> '$TARGET_FS_ROOT/$rule'"

with

# Do not error out at this late state of "rear recover" (after the backup was restored) but inform the user:
cp $v "$rule" "$TARGET_FS_ROOT/$rule" || LogPrintError "Failed to copy '$rule' to '$TARGET_FS_ROOT/$rule'"

cf. https://github.com/rear/rear/issues/1972#issuecomment-440251103
and my recent adaptions in finalize/GNU/Linux/280_migrate_uuid_tags.sh at
https://github.com/rear/rear/pull/2047/commits/6b1889cbf7bed297a5a695fd01f52865c4527827#diff-5700db308d823937817e66eaa11ec7fd

gdha commented at 2019-03-05 12:58:

@rmetrich Will tis little fix be included in the RHEL rear-2.0 or rear-2.4 release?

rmetrich commented at 2019-03-05 13:01:

@gdha I don't think so, not now at least, we had no customer facing this.

rmetrich commented at 2019-03-05 13:02:

@pcahyna is dealing with RHEL ReaR package.

pcahyna commented at 2019-03-05 13:26:

I don't remember any report about ReaR on VMware. I suspect ReaR is most used on physical machines or LPARs.
How does the problem manifest itself? Is it loss of network connectivity in the rescue system?

gdha commented at 2019-03-05 13:56:

@pcahyna @rmetrich Within the Johnson & Johnson group we have quite a few VMware systems suffering from this missing file in the udev rule (at least from systems build with RHEL 7.2 or 7.3):
During the recovery we had issues with:

LAN interface name being ens192 instead of "eno16780032"
LAN interface name being ens224 instead of "eno33559296"

In a following up session we modified

RULE_FILES=( /etc/udev/rules.d/*persistent*{names,net}.rules /etc/udev/rules.d/*eno-fix.rules )

in script skel/default/etc/scripts/system-setup.d/55-migrate-network-devices.sh which activated LAN interface migration questions during the recovery booting and we could apply our IP addresses on the new interfaces correctly.
Our DR recovery went fluent afterwards.

pcahyna commented at 2019-03-05 14:41:

Ah, so the network interfaces will have different names in the rescue system. Is that really a problem after @rmetrich's #2004 is integrated?

gdha commented at 2019-03-05 15:04:

@pcahyna yes, as the /etc/udev/rules.d/90-eno-fix.rules overrules the ifcfg files.
However, if we remove the /etc/udev/rules.d/90-eno-fix.rules via BACKUP_RESTORE_MOVE_AWAY_FILES=( /etc/udev/rules.d/90-eno-fix.rules ) setting in the local.conf then no
So, if you let me know in which release of RHEL rear the #2004 will be included we can fix this via our internal rear chef cookbook.

pcahyna commented at 2019-03-05 17:40:

@pcahyna yes, as the /etc/udev/rules.d/90-eno-fix.rules overrules the ifcfg files.

Does that mean that (with #2004 and without this PR) the rescue system will work, but the restored system will be wrongly configured? I.e. even with #2004 included, we should include this PR?

However, if we remove the /etc/udev/rules.d/90-eno-fix.rules via BACKUP_RESTORE_MOVE_AWAY_FILES=( /etc/udev/rules.d/90-eno-fix.rules ) setting in the local.conf then no
So, if you let me know in which release of RHEL rear the #2004 will be included we can fix this via our internal rear chef cookbook.

We intend to include #2004 in the next update.

gdha commented at 2019-03-06 08:01:

@pcahyna yes, as the /etc/udev/rules.d/90-eno-fix.rules overrules the ifcfg files.

Does that mean that (with #2004 and without this PR) the rescue system will work, but the restored system will be wrongly configured? I.e. even with #2004 included, we should include this PR?

Yes that is what we discovered. My advise would be to include it as it targets only a small group of VMware users and cannot do any harm for the others

We intend to include #2004 in the next update.

Great news.

pcahyna commented at 2019-03-06 14:30:

I can not reproduce the underlying issue on VMWare ESXi 5.5 btw. in RHEL 7.2 using the vmxnet3 driver. The network interface is called ens192 instead of eno something.

pcahyna commented at 2019-03-06 14:41:

This approach of adding special cases to the code does not seem to be well maintainable. Would it be possible to recreate the host configuration in the rescue system as faithfully as possible by adding everything under /etc/udev/rules.d/ ?

gdha commented at 2019-03-06 14:54:

@pcahyna if you want to simulate the behavior under your test environment you can do the following:

cd /etc/sysconfig/network-scripts
mkdir backup

cp ifcfg-ens224 backup
ethtool -P ens224
mv ifcfg-ens224 ifcfg-eno33559296

cp ifcfg-ens192 backup
ethtool -P ens192
mv ifcfg-ens192 ifcfg-eno16780032

vi ifcfg-eno33559296
and comment the line starting with HWADDR
and rename ens224 into eno33559296

vi ifcfg-eno16780032
and comment the line starting with HWADDR
and rename ens192 eno16780032

cd /etc/udev/rules.d/
vi 90-eno-fix.rules
[expected output]

   # This file was automatically generated on systemd update
   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:9b:99:d6", NAME="eno16780032"
   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:9b:89:98", NAME="eno33559296"

 ==> change MAC addresses of two lines with above info from 'ethtool' command

Reboot the system

[Export of Github issue for rear/rear.]