Bug 1016319 - New vNICs pull from lowest MAC address when added to guest
New vNICs pull from lowest MAC address when added to guest
Status: CLOSED DUPLICATE of bug 737564
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.2.0
x86_64 Linux
unspecified Severity medium
: ---
: 3.4.0
Assigned To: nobody nobody
Meni Yakove
network
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-07 18:18 EDT by wdaniel
Modified: 2016-02-10 14:51 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-17 12:38:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wdaniel 2013-10-07 18:18:39 EDT
Description of problem:

Customer is provisioning large numbers of VMs in his environment and assigns different VLANs to different vNICs before an OS gets installed/set up. Regardless of the creation/addition time of the vNIC to the guest, RHEL appears to name the interface in sequential order according to the MAC address (lower MAC addr gets lower eth[0-9] name).

In this customer's case, he has VLANs assigned to the NICs before the VM is set up and the software that is running is dependant on the naming scheme of the NICs. Due to this behavior, his interface names are mismatched with the NICs causing manual override of the naming after a VM is set up. 

From the customer:


For example, if I have a vm creation request that calls for eth0=VLAN_3000 and eth1=VLAN_4000...

1. Create nic1
Name: nic1
VLAN: 3000
Auto assigned MAC - 00:1a:4a:12:50:c3

2. Create nic2
Name: nic2
VLAN: 4000
Auto assigned MAC - 00:1a:4a:12:50:c0


Now when the VM boots, nic2 = eth0 and nic1 = eth1.
If I try and remove the nics and recreate, the same mac addresses get assigned and I'm back where I started.

To fix, I have to do the following:
1. switch nic2 to use vlan3000
2. switch nic1 to use vlan4000
3. rename nic2 to nic1_tmp (because of conflict)
4. rename nic1 to nic2
5. rename nic1_tmp to nic1

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

How reproducible:
100%

Actual results:
MAC addresses assigned to the vNICs are not in a sequential order in line with their creation/addition to the VM

Expected results:
As additional vNICs are added, the MAC address increases according to pool availability so that the creation/addition order to the VM matches the sequential order of the MAC addresses.

Additional info:
Comment 1 Moti Asayag 2013-10-09 08:50:30 EDT
(In reply to wdaniel from comment #0)
> Description of problem:
> 
> Customer is provisioning large numbers of VMs in his environment and assigns
> different VLANs to different vNICs before an OS gets installed/set up.
> Regardless of the creation/addition time of the vNIC to the guest, RHEL
> appears to name the interface in sequential order according to the MAC
> address (lower MAC addr gets lower eth[0-9] name).

The engine is incapable to control the internal devices names which might be allocated either by the udev or by the biosdevname for linux (i'm not familiar with the method used for that in windows guests) and it seems that behaviour might change according to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ which specifically raises concern regarding relying on the mac addresses for configuring the device.

For rhel, a user can override the /etc/udev/rules.d/70-persistent-net.rules with its desired configuration and leverage the cloud-init integration with ovirt (via the run-once) to set for in the VM (however it seems it requires a reboot of the vm since the cloud-init service runs later than the udev).

> 
> In this customer's case, he has VLANs assigned to the NICs before the VM is
> set up and the software that is running is dependant on the naming scheme of
> the NICs. Due to this behavior, his interface names are mismatched with the
> NICs causing manual override of the naming after a VM is set up. 
> 
> From the customer:
> 
> 
> For example, if I have a vm creation request that calls for eth0=VLAN_3000
> and eth1=VLAN_4000...
> 
> 1. Create nic1
> Name: nic1
> VLAN: 3000
> Auto assigned MAC - 00:1a:4a:12:50:c3
> 
> 2. Create nic2
> Name: nic2
> VLAN: 4000
> Auto assigned MAC - 00:1a:4a:12:50:c0
> 
> 
> Now when the VM boots, nic2 = eth0 and nic1 = eth1.
> If I try and remove the nics and recreate, the same mac addresses get
> assigned and I'm back where I started.
> 
> To fix, I have to do the following:
> 1. switch nic2 to use vlan3000
> 2. switch nic1 to use vlan4000
> 3. rename nic2 to nic1_tmp (because of conflict)
> 4. rename nic1 to nic2
> 5. rename nic1_tmp to nic1
> 
> Version-Release number of selected component (if applicable):
> RHEV 3.2
> 
> How reproducible:
> 100%
> 
> Actual results:
> MAC addresses assigned to the vNICs are not in a sequential order in line
> with their creation/addition to the VM
> 
> Expected results:
> As additional vNICs are added, the MAC address increases according to pool
> availability so that the creation/addition order to the VM matches the
> sequential order of the MAC addresses.
> 
> Additional info:

Does the purpose of the specific assignment is to determine the order of the boot ? If so, we can close this bug as a duplicate of Bug 737564, which on comment #29 describes the exact scenario as in this bug.

If not, could you explain what is the concern about matching nic1-eth0 and nic2-eth1 other than to determine the boot sequence ?
Comment 3 Dan Kenigsberg 2013-10-10 20:12:50 EDT
We have three enumerables:
[1] oVirt nic names (nic1,nic2..)
[2] mac addresses
[3] guest device names (eth0,p1p2,em1..).

The customer requests that there would be a predictable relation between [1] and [3]. Since the [2]-[3] relation is guest-dependable and not predictable, and since ovirt controls only the [1]-[2] relation, we cannot guarantee the request.

Even for a specific guest operation system, havin a predictable 2-3 relation of giving "eth0" to the least of macs, predictability is hard to guarantee. When one plugs a new vNIC to an old VM, one cannot assume to find a free mac address that is higher than all assigned addresses.

If the customer does not add new vNIC during the VM lifecycle, we could suggest a script to be run before a VM is first started. That script could edit the MAC addresses[2] to mach the natural order of nic names[1].

Would that satisfy the customer?
Comment 4 wdaniel 2013-10-17 12:38:25 EDT
Dan,

I really appreciate your explanation in the previous comment. After talking to the customer it sounds more and more like this is a duplicate of Bug #737564. I will be closing this bug and attaching the customer's case to the previous bug. 

Thanks for your help,
Wallace

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

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