This issue will be fixed on 3.5.4
see - https://bugzilla.redhat.com/show_bug.cgi?id=1203422
On 3.5.3, vdsm generating all ifcfg-* files to ONBOOT=NO by default, except the management
network and the interface it is attached to. In your case bond (bond0,bond.108 and the
- You can configure your ifcfg-* files manually to ONBOOT=yes and restart network service
as a workaround for now.
----- Original Message -----
From: "Simon Barrett" <Simon.Barrett(a)tradingscreen.com>
Sent: Monday, August 24, 2015 5:01:45 PM
Subject: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues?
I’m running into a problem with my upgrades to oVirt 3.5.3 and wanted to check if the
following is a known issue.
I have multiple vlan tagged interfaces configured. The files are being generated as
expected by vdsm. The vlan 108 interface below is used by the ovirtmgmt bridge. The
uatdev_ben, bond0.192, dev_office, bond0.124 interface definitions all have ONBOOT=no.
root@host> grep -i onboot ifcfg* | grep -v bak
The persistence configuration files are where they should be (I think):
root@host> ls -l /var/lib/vdsm/persistence/netconf/nets/
-rw-r--r-- 1 root root 121 Aug 24 22:44 dev_office
-rw-r--r-- 1 root root 173 Aug 24 22:44 ovirtmgmt
-rw-r--r-- 1 root root 121 Aug 24 22:44 uatdev_ben
If I were to do a “service network restart” on the node, the uatdev_ben, dev_office,
bond0.124 & bond0.192 are removed and then not restored as the “ONBOOT=no”. I assumed
that vdsmd would re-create the dev_office and uatdev_ben interfaces so restarted vdsmd but
they were not restored. I tried a “vdsm-tool restore-nets” to see if that would restore
the interfaces but no joy.
Am I missing something? Is there another method I should use to recover the missing
interfaces? Should the ifcfg files all be configured with “ONBOOT=yes” just in case
someone does run a “service network restart”?
My oVirt nodes are CentOS 6.5, I’m not using the node iso.
Many thanks in advance for any assistance.
Users mailing list
RedHat Israel, RHEV-M QE Network Team