RHEV hypervisors are losing bond interfaces after upgrade to RHEV 3.5

Solution Verified - Updated -

Environment

  • vdsm-4.16.8.1-6.el6ev
  • Red Hat Enterprise Virtualization Hypervisor (RHEV-H)
  • Red Hat Enterprise Linux hypervisor (RHEL-H)

Issue

RHEV hypervisor lost a bonding interface after upgrade. Ifcfg-bond* devices that were defined manually outside of VDSM are removed and VDSM fails to restore the network that depends on them.

Resolution

The issue has been resolved in vdsm-4.16.13.1-1.el6ev and corresponding RHEV-H release is rhev-hypervisor6-6.6-20150421.0.el6ev.

[More Info]: How to troubleshoot new network implementation in vdsm-4.16.8.1 and higher

Root Cause

There are a few bugs opened for these issues:

1) VDSM does not consume predefined ifcfg interfaces, and does not consider them as its own. However, with unified persistence, which is the default in RHEV 3.5, ifcfg files of devices that are used by a VDSM network are being removed on VDSM startup.
This bug was opened and fixed in the latest 3.5.z async release - vdsm-4.16.8.1-8.el6ev:
Bug 1197668 - After failure to setupNetworks: restore-nets with unified persistence does not restore pre-vdsm ifcfg

2) Lost bond devices right after upgrade, no setupNetwork attempt is involved. Probably occurs when the bond has a VLAN tag assigned.
This issue is tracked in bug:
Bug 1194553 - VDSM script reset network configuration on every reboot when based on predefined bond

3) VDSM sets onboot=no and the network is not accessible after a restart.
This issue is tracked in bug:
Bug 1194068 - RHEV Hypervisor 20150128 sets network interfaces to ONBOOT=no during reboot/upgrade

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