This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 831668 - network is not brought up when run in a VM with multiple NICs [NEEDINFO]
network is not brought up when run in a VM with multiple NICs
Status: CLOSED NEXTRELEASE
Product: oVirt
Classification: Community
Component: ovirt-node (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fabian Deutsch
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-13 10:36 EDT by Fabian Deutsch
Modified: 2016-04-26 10:12 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.5.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-27 05:21:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
fdeutsch: needinfo?


Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2012-06-13 10:36:51 EDT
Description of problem:
An autoinstall using firstboot and BOOTIF=eth0 (eth0 exists) doesn't bring up networking.
This could already be broken in 2.3.0

Version-Release number of selected component (if applicable):
F17 builds
Comment 1 Fabian Deutsch 2012-06-18 04:30:41 EDT
The network cards are named differently on firstboot and after the installation.
Ths ifcfg scripts contain a wrong dev/mac mapping.
Comment 2 Fabian Deutsch 2012-06-20 03:09:57 EDT
Problem:
In a multi NIC setup, the order of NICs is unstable on F17 based installs but just if biosdevname is not actiavted/working.
This is the case for VMs, where biosdevname is deactivated so that - if multiple NICs are assigned - their order can change between reboots.

(a) bug #824595 would help to solve this problem.

(b) Alternatively it could help if the hypervisor provides enough informations about the nics for biosdevname which was talked about in bug #669955

If the problem exists just in this corner case (Node in a VM) we should push this into the future, as it is not relevant in practice, except when doing automated testing.
Comment 3 Fabian Deutsch 2012-07-24 10:18:34 EDT
This seems to be fixed by bug #824595

Tested as follows:
1. Install a recent node with patch from given bug and the additional kargs BOOTIF=eth0 storage_init firstboot
2. After reboot, log in to the TUI
3. Check that the network is up (IP address given)
Comment 4 Fabian Deutsch 2012-07-27 05:21:50 EDT
Fixed with bug #824595

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