The order of network interfaces mismatch between VMWare vSphere Client GUI and VM

Question

I have an ova template. 6 network interfaces are defined in it, named net0, net1, net2, net3, net4, net5. The type of all of them is VMXNET3.

When I deploy this ova template to ESXi6.0/5.5 server, one of steps is to configure the mapping from network name (net0, net1, ..., net5) to existing networks on ESXi server (like vlan500, vlan501, ..., vlan505), like:

net0 -> vlan500
net1 -> vlan501
... ...
net5 -> vlan505

After the VM instance powers on, in the VM instance, there are 6 eth network interfaces: eth0, eth1, ..., eth5.

I expect the order of ethX inside VM should be same as the order of adapters outside VM like:

eth0 -> net0 -> vlan500
eth1 -> net1 -> vlan501
... ...
eth5 -> net5 -> vlan505

But I find I get this by checking the MAC addresses:

eth0 -> net0 -> vlan500
eth1 -> net4 -> vlan504    <= mismatch
eth2 -> net1 -> vlan501    <= mismatch
eth3 -> net5 -> vlan505    <= mismatch
eth4 -> net2 -> vlan502    <= mismatch
eth5 -> net3 -> vlan503    <= mismatch

Can you please help to point out how to resolve this issue?

Thanks in advance!

The ovf xml is like following:

125       <Item>
126         <rasd:AddressOnParent>7</rasd:AddressOnParent>
127         <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
128         <rasd:Connection>NET0</rasd:Connection>
129         <rasd:Description>VmxNet3 ethernet adapter on "NET0"</rasd:Description>
130         <rasd:ElementName>Ethernet 1</rasd:ElementName>
131         <rasd:InstanceID>10</rasd:InstanceID>
132         <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
133         <rasd:ResourceType>10</rasd:ResourceType>
134         <vmw:Config ovf:required="false" vmw:key="slotInfo.pciSlotNumber" vmw:value="32" />
135         <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true" />
136       </Item>
137       <Item>
138         <rasd:AddressOnParent>8</rasd:AddressOnParent>
139         <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
140         <rasd:Connection>NET1</rasd:Connection>
141         <rasd:Description>VmxNet3 ethernet adapter on "NET1"</rasd:Description>
142         <rasd:ElementName>Ethernet 2</rasd:ElementName>
143         <rasd:InstanceID>11</rasd:InstanceID>
144         <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
145         <rasd:ResourceType>10</rasd:ResourceType>
146         <vmw:Config ovf:required="false" vmw:key="slotInfo.pciSlotNumber" vmw:value="33" />
147         <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true" />
148       </Item>
149       <Item>
150         <rasd:AddressOnParent>9</rasd:AddressOnParent>
151         <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
152         <rasd:Connection>NET2</rasd:Connection>
153         <rasd:Description>VmxNet3 ethernet adapter on "NET2"</rasd:Description>
154         <rasd:ElementName>Ethernet 3</rasd:ElementName>
155         <rasd:InstanceID>12</rasd:InstanceID>
156         <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
157         <rasd:ResourceType>10</rasd:ResourceType>
158         <vmw:Config ovf:required="false" vmw:key="slotInfo.pciSlotNumber" vmw:value="34" />
159         <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true" />
160       </Item>
161       <Item>
162         <rasd:AddressOnParent>10</rasd:AddressOnParent>
163         <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
164         <rasd:Connection>NET3</rasd:Connection>
165         <rasd:Description>VmxNet3 ethernet adapter on "NET3"</rasd:Description>
166         <rasd:ElementName>Ethernet 4</rasd:ElementName>
167         <rasd:InstanceID>13</rasd:InstanceID>
168         <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
169         <rasd:ResourceType>10</rasd:ResourceType>
170         <vmw:Config ovf:required="false" vmw:key="slotInfo.pciSlotNumber" vmw:value="35" />
171         <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true" />
172       </Item>
173       <Item>
174         <rasd:AddressOnParent>11</rasd:AddressOnParent>
175         <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
176         <rasd:Connection>NET4</rasd:Connection>
177         <rasd:Description>VmxNet3 ethernet adapter on "NET4"</rasd:Description>
178         <rasd:ElementName>Ethernet 5</rasd:ElementName>
179         <rasd:InstanceID>14</rasd:InstanceID>
180         <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
181         <rasd:ResourceType>10</rasd:ResourceType>
182         <vmw:Config ovf:required="false" vmw:key="slotInfo.pciSlotNumber" vmw:value="36" />
183         <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true" />
184       </Item>
185       <Item>
186         <rasd:AddressOnParent>12</rasd:AddressOnParent>
187         <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
188         <rasd:Connection>NET5</rasd:Connection>
189         <rasd:Description>VmxNet3 ethernet adapter on "NET5"</rasd:Description>
190         <rasd:ElementName>Ethernet 6</rasd:ElementName>
191         <rasd:InstanceID>15</rasd:InstanceID>
192         <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
193         <rasd:ResourceType>10</rasd:ResourceType>
194         <vmw:Config ovf:required="false" vmw:key="slotInfo.pciSlotNumber" vmw:value="37" />
195         <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true" />
196       </Item>

score 1 · Answer 1 · answered Feb 08 '17 at 13:46

I guess that Linux is the OS inside the VM.

I'm not Linux administrator but recently I've try to resolve something similar to your problem with my colegue. In our situation NIC that was eth0 becomes eth1 after deployment. It was because eth(x) name was assigned by MAC address of NIC. And MAC address is allways different after deploying ovf template (if you deploy that template to the same environment then it have to change to avoid conflicts; if environment is different - then first segments in MAC address are different by default). I'm not linux administrator so I'm not sure that always (in every distribution) is the same mapping NIC->eth(x) policy.

So you have to check how OS maps NIC to eth(x) names. If there is any way to make mapping based on PCI position then you can do it, because that information is in ovf file. If mapping is done ONLY based on MAC address then it will be impossible to map correctly, because MAC address is not written to ovf file.

It looks like my VMWare does not honor the slot information in ovf file. Otherwise, guest Linux would recognize the order correctly by pci slot number, just as the guest Linux does in KVM VM. I would expect that advanced VMWare software would not hit this issue. But I don't have fully licenses for them. Now, I use KVM. — Ming Lu, Feb 10 '17 at 04:40

score 0 · Answer 2 · answered Oct 02 '17 at 13:08

The issue isn't vmware, it's your vm. When you clone a vm, or if your ova wasn't properly prepped, eth0 won't be usable because the mac adress is in the /etc/sysconfig/network-scripts/ifcfg-eth0 script as well as in the /etc/udev/rules.d/70-persistent-net.rules file. You have 2 choices.

Change the mac in both the 70-persistent-net.rules and ifcfg-eth0 to match your new mac
Delete the 70-persistent-net.rules and remove the HWADDR from the ifcfg-eth0

After a reboot, you should have eth0 working again.

The order of network interfaces mismatch between VMWare vSphere Client GUI and VM

2 Answers2