Bug 831668 - network is not brought up when run in a VM with multiple NICs [NEEDINFO]
Summary: network is not brought up when run in a VM with multiple NICs
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-node
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Fabian Deutsch
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-13 14:36 UTC by Fabian Deutsch
Modified: 2016-04-26 14:12 UTC (History)
7 users (show)

Fixed In Version: 2.5.0
Clone Of:
Environment:
Last Closed: 2012-07-27 09:21:50 UTC
oVirt Team: ---
Embargoed:
fdeutsch: needinfo?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 669955 0 low CLOSED Implement support for SMBIOS Type 41 structures 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 824595 0 unspecified CLOSED /etc/udev/rules.d/70-persistent-net.rules not persistant by default 2021-02-22 00:41:40 UTC

Internal Links: 669955 824595

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


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