Hi All,
After playing with it a bit i think there is a problem with vmxnet3 devices. I found a work around for this, but first let me explain the problem:
Currently the RHEL6 is using the /etc/udev/rules.d/70-persistent-net.rules to determine the naming of eth's. if this file is missing on boot it will be re-created, and the order of the NIC's will be decided by there BUS ID.
When i checked e1000 virtual NIC's i found out the bus ID assigned is sequential - when a new NIC is added, it will get the next availble bus ID. While in vmxnet3 - it is not sequential. Here is what happen when i add a new nic to a 3 nic's system:
3 NICS:
-------------
[root@dscs1 ~]# lspci | grep -i eth
0b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
13:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
1b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) --> NEW
4 NICS:
-------------
[root@dscs1 ~]# lspci | grep -i eth
04:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) --> NEW
0b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
13:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
1b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
My soultion is based on that the even if the vmxnet3 bus ID is not sequential, it is allways the same - meaning any new/cloned system will allways get the same BUS ID.
So - we created a new udev rules file for RHEL6, and set it to process before the 70-persistent-net.rules. Instead of using the macaddress to identify the NIC, i use the BUS ID.
This is how it looks like:
--------------------------------------------
# cat /etc/udev/rules.d/69-vmxnet3-net.rules
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:0b:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:13:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:1b:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:04:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:0c:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:14:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:1c:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:05:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"
---------------------------------------------
As you can see there is no MAC address. Instead it uses the bus ID ("KERNELS") as key. It is also applies to vmxnet3 drivers only.
This solved the issue to me - it also solved the problem with removing the 70-persistent-net.rules after/before any clone.
Some notes to consider, if you want to use it:
1. This file us limited up to 8 nics - if you need more then you should add new lines with the bus ID.
2. Since it only apply to vmxnet3 nics - if you set your system with e1000 nics, this rule will not apply on it, and the regular 70-persistent-net.rules will be created to map it.
3. I assume each system is using one type of nics (either e1000 OR vmxnet3), not both toghter - on our systems we don't use "mix" of e1000 and vmxnet3 - if you do - you should test how it behaves before - on your own risk.
Hope this post will help someone.
Best Regards,
Dori
