Bug 831668

Summary: network is not brought up when run in a VM with multiple NICs
Product: [Retired] oVirt Reporter: Fabian Deutsch <fdeutsch>
Component: ovirt-nodeAssignee: Fabian Deutsch <fdeutsch>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, dyasny, jboggs, mburns, mgoldboi, ovirt-bugs, ovirt-maint
Target Milestone: ---Flags: fdeutsch: needinfo?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 2.5.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-27 09:21:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fabian Deutsch 2012-06-13 14:36:51 UTC
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 08:30:41 UTC
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 07:09:57 UTC
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 14:18:34 UTC
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 09:21:50 UTC
Fixed with bug #824595