Why do interface configuration file gets renamed to "ifcfg-ethX.back" in RHEL 5.9 Guest VM running on Microsoft Hyper-V environment?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 5.9

  • Microsoft Hyer-V

Issue

  • MAC address of RHEL 5.9 Guest VM changed during a reboot or migration from one host to another (not sure what caused it)

  • when this occurred, the "ifcfg-eth0" file is now named "ifcfg-eth0.bak" (with original assigned MAC, IP, etc.) and now there is a new "ifcfg-eth0" file with a new MAC and missing IP, etc.

  • What causes such renames to occur?

Resolution

  • The underlying hyper-v was configured to use dynamic MAC address which means that it will generate an initial MAC address for the network adapter, and it will regenerate the MAC address if it believes it is necessary.

  • This cause can the mac-id of guest to differ from exiting on and there by kudzu try to load the NIC with new address and renaming the older configuration as ifcfg-ethX.bak.

Root Cause

  • The guest is configured with dynamic mac address feature at the hyper-V level. This dynamic mac address pool can be defined for each hyper-v host differently. This can cause re-generation of mac addresses under following circumstance:

    • The virtual machine is being turned on and the current MAC address is outside of the MAC address range configured for the current Hyper-V server.

    • The virtual machine is being turned on, or is restored from a saved state, and Hyper-V detects that another virtual machine is already using the specified MAC address.

    • The virtual machine is being turned on, or is restored from a saved state, and Hyper-V detects that the dynamic MAC address value in the virtual machine configuration has been set to zero.

  • This phenomenon is an expected behavior to see since, in this situation when the VM gets migrated, and the mac address of the NIC changes from the hypervisor level, the UDEV and kudzu in RHEL5 guest interprets it as a new device and will perform a renaming of older device.

  • Disabling kudzu can alleviate from NIC renaming problem. But the real issue needs to be identified at hyper-V level to understand why the NIC mac-address changes after migration and rebooting the guest.

Diagnostic Steps

  • Dmesg logs indicetes checksum feature is missing:
hv_vmbus: registering driver hv_netvsc
eth0: Dropping NETIF_F_SG since no checksum feature.  <<<---------
hv_netvsc: hv_netvsc channel opened successfully
hv_netvsc vmbus_0_13: Device MAC 00:15:5d:e1:4e:c8 l
  • There are two files ifcf-ethX and ifcfg-ethX.bak file seen after reboot. The older NIC complete goes missing on the host.
cat etc/sysconfig/network-scripts/ifcfg-eth0
Microsoft Corporation Hyper-V Network Adapter
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
HWADDR=00:15:5d:e1:4e:c8
IPADDR=1.2.3.4
NETMASK=255.255.255.0

cat etc/sysconfig/network-scripts/ifcfg-eth0
ifcfg-eth0      ifcfg-eth0.bak  

cat etc/sysconfig/network-scripts/ifcfg-eth0.bak 
# Microsoft Corporation Hyper-V Network Adapter
DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:15:5D:E1:32:A2
IPADDR=1.2.3.4
NETMASK=255.255.255.0
ONBOOT=yes

  • The older interface went completely missing from the host which makes me believe that this can happen due to misconfiguration or interface changes at the hypervisor layer itself since RHEL is a VM it will only see the emulated device provided to it and will be unaware of any changes happened in the virtualization layer.

  • This change in hypervisor layer for the interface triggered kudzu to detect it as a new device and replace the NIC interface configuration file with the new one.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments