Bug 1045022

Summary:	[RFE] Virtual pxe boots out of order - NICs ordered according to the MAC addresses
Product:	[Retired] oVirt	Reporter:	Omer Frenkel <ofrenkel>
Component:	ovirt-engine-core	Assignee:	Arik <ahadas>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Meni Yakove <myakove>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.4	CC:	acathrow, amedeo, iheim, mavital, michal.skrivanek, nicolas, pep, tdosek, yeylon
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:	ovirt-3.4.0-alpha1	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-31 15:04:16 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:
Bug Depends On:
Bug Blocks:	737564

Description Omer Frenkel 2013-12-19 13:17:13 UTC

The default sorting of network interfaces is according to their MAC addresses. 
The boot order of network interfaces is also set such that the NIC with the lowest MAC address was getting the lowest boot index, 
and the one with the highest MAC address was getting the highest boot index.

We would want to set the boot order for NICs such that it
will be set according to their names instead of their MAC addresses.

Comment 1 Sandro Bonazzola 2014-01-13 13:56:28 UTC

oVirt 3.4.0 alpha has been released including the fix for this issue.

Comment 3 Sandro Bonazzola 2014-03-31 15:04:16 UTC

This is an automated message: moving to Closed CURRENT_RELEASE since oVirt 3.4.0 has been released.

Comment 4 Nicolas Ecarnot 2015-03-31 08:22:36 UTC

Hello,

Using 3.5.1, in a fresh Vm with no disk and two NICs :

- eth1 : 00:1a:4a:bb:00:05
- eth3 : 00:1a:4a:bb:00:06

When PXE booting, the VNC console and the DHCP server logs are showing that eth3 is used first to run a DHCP chat.
I was expecting eth1 to be used first.

For me, this bug is not solved. (Or maybe I misunderstood the resolution)

(It is an issue for us because many of our VMs are using a NIC for their network and a second one for the iSCSI access.
When provisionning them, our automated setup relies on the correct PXE boot via the correct NIC, leading to some kickstart installation.)