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:
(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 ?
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?
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 ***