Bug 845944 - bootstrap | RHEVM onboot set to no if onboot of ethX was no
bootstrap | RHEVM onboot set to no if onboot of ethX was no
Status: CLOSED DUPLICATE of bug 847733
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm (Show other bugs)
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Dan Kenigsberg
Meni Yakove
Depends On:
  Show dependency treegraph
Reported: 2012-08-06 04:08 EDT by Meni Yakove
Modified: 2012-08-23 16:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-23 16:29:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Meni Yakove 2012-08-06 04:08:54 EDT
Description of problem:
I have host with eth2 that ifcfg-eth2 cfg is:

I have add the host to RHEVM and install it.
The newly created RHEVM ifcfg file look like this:

The RHEVM cfg file have two onboot one with yes and one with no, After reboot RHEVM bridge is down.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Host with ethX that have onboot=off
2.Add the host to RHEVM and install it.

Actual results:
After reboot RHEVM bridge not up, The hosty is non-operational

Expected results:
After reboot RHEVM bridge is up, shouldn't be onboot=no on RHEVM cfg file.
Comment 2 lpeer 2012-08-06 04:25:42 EDT
In the bootstrap process the management bridge parameters are copied from the nic the bridge is connected to (in this case the ONBOOT=no).

In addition the bootstrap is adding a few parameter of it own (ONBOOT=yes).

We are missing the logic to skip copying the ONBOOT property from the bridge.
Comment 3 Dan Kenigsberg 2012-08-23 16:29:00 EDT
I believe that the root cause for this is that ONBOOT is passed as-is to the internal functions, and not converted to lowercase - just as in bug 847733.
Thus, I think that this should be solved by


*** This bug has been marked as a duplicate of bug 847733 ***

Note You need to log in before you can comment on or make changes to this bug.