Template Win 2008R2 VMXnet3 adapter ordering problem

[Marco115]

Hello all,

I have created a vmware template of Windows 2008R2 with 3 VMXnet3 adapters. Before the template is shutdown I remove the 3 VMXnet3 nics from Windows. The problem that rises when the template is deployed to a new virtual machine is that the nic order in VMware and Windows are applied in random order. You would expect that everytime you deploy the template to a new virtual machine the following order is applied:

Windows: Local Area Connection = VMware: vmxnet3 Ethernet Adapter

Windows: Local Area Connection 2 = VMware: vmxnet3 Ethernet Adapter #2

Windows: Local Area Connection 3 = VMware: vmxnet3 Ethernet Adapter #3

The problem is that every time a template is deployed to a new virtual machine the adapters gets ordered differently. As an example:

Windows: Local Area Connection = VMware: vmxnet3 Ethernet Adapter #2

Windows: Local Area Connection 2 = VMware: vmxnet3 Ethernet Adapter

Windows: Local Area Connection 3 = VMware: vmxnet3 Ethernet Adapter #3

This is quitte annoying when you want to use a standard for applying VLAN's to VMware nics.

I hope that somebody has a solution for this problem.

Grts, Marco

[vMario156]

Hi Marco,

thats happening because if you deploy a template a new MAC address is generate, so Windows detects a new nic (and still know the old one from the template creation process).

Easy solution: Just uninstall the nic (Windows - device manager) in the last step when you creating the template.

Regards,

Mario

[Marco115]

Hi Mario,

Thanks for the fast reply. But as I already explained in my question, I already uninstall the nics before I convert the virtual machine to a template but the problem still arises....

Regards, Marco

[vMario156]

Sorry Marco,

I read your post much to fast

Hm at least from a VMware perspective I can´t imagin a way to get around it / influence it.

To ideas / workarounds:

a) Leave two of the vmnics unconnected. After deployed the VM connect them step by step. Sure this is still a manual step but if Windows than gets the correct order thats much more easy than renaming the connections within Windows.

b) Using a "one-time" powershell script within Windows to do a automatic renaming after the first boot. If you are using the Customization Specifications Manager you can just add it there, if not you would need to include that this script is deleted after it has run successfull

Regards,

Mario

[Marco115]

Hi Mario,

Thanks for the workaround tips, I was looking in the same direction already, but renaming is the nics not really the problem.

I would really like it if the adapters in Windows always use the same adapter in VMware. The random ordering is what is bothering me because it makes it impossible to always apply the same VLAN's in the same order to the VMware adapters. The only posible way to solve this now is indeed disconnecting two adapters in VMware, but I rather prevent the manual actions. I also really would like to prevent human errors and ending up with the wrong VLAN's on the adapters because they change with every VM deployed.....

Regards, Marco

[MKguy]

AFAIK Windows numbers the NICs (like Linux) according to the PCI addresses. This is displayed in the device manager under "Location", e.g.:

PCI Slot 192 (PCI bus 11, device 0, function 0)

Can you compare the PCI address information in the VM(T)X files between your template and a couple of deployed VMs?

I only have one NIC but things looks like this here:

# grep -i 'ethernet[0-9]\.pci' /vmfs/volumes/Datastore2/TemplateW2K8/TemplateW2K8.vmtx | sort

ethernet0.pciSlotNumber = "192"

# grep -i 'ethernet[0-9]\.pci' /vmfs/volumes/Datastore1/SomeVM99/SomeVM99.vmx | sort
ethernet0.pciSlotNumber = "192"

# grep -i 'pci' /vmfs/volumes/Datastore2/TemplateW2K8/TemplateW2K8.vmtx | sort
ethernet0.pciSlotNumber = "192"
pciBridge0.pciSlotNumber = "17"
pciBridge0.present = "true"
pciBridge4.functions = "8"
pciBridge4.pciSlotNumber = "21"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge5.pciSlotNumber = "22"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge6.pciSlotNumber = "23"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
pciBridge7.pciSlotNumber = "24"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
scsi0.pciSlotNumber = "160"
vmci0.pciSlotNumber = "32"

# grep -i pci /vmfs/volumes/Datastore1/SomeVM99/SomeVM99.vmx | sort
ethernet0.pciSlotNumber = "192"
pciBridge0.pciSlotNumber = "17"
pciBridge0.present = "true"
pciBridge4.functions = "8"
pciBridge4.pciSlotNumber = "21"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge5.pciSlotNumber = "22"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge6.pciSlotNumber = "23"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
pciBridge7.pciSlotNumber = "24"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
scsi0.pciSlotNumber = "160"
vmci0.pciSlotNumber = "32"

Note in my example:
pciBridge0.pciSlotNumber = "17"
Could correspond to "PCI bus 11" displayed in the Windows device properties (11 in hex = 17 decimal).

[Marco115]

Hi MKguy, thanks for the repsonse. I checked this out on my template vm and a vm deployed with the template where the adapters are in different order. I do not see any differences in the grep output.

grep -i ethernet[0-9]\.pci Templ_W2K8R2-ENT-SP1-US-VL-FULL_.vmx |sort
ethernet0.pciSlotNumber = "224"
ethernet1.pciSlotNumber = "256"
ethernet2.pciSlotNumber = "1184"

grep -i pci Templ_W2K8R2-ENT-SP1-US-VL-FULL_.vmx |sort
ethernet0.pciSlotNumber = "224"
ethernet1.pciSlotNumber = "256"
ethernet2.pciSlotNumber = "1184"
pciBridge0.pciSlotNumber = "17"
pciBridge0.present = "true"
pciBridge4.functions = "8"
pciBridge4.pciSlotNumber = "21"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge5.pciSlotNumber = "22"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge6.pciSlotNumber = "23"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
pciBridge7.pciSlotNumber = "24"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
scsi0.pciSlotNumber = "160"
scsi1.pciSlotNumber = "192"
vmci0.pciSlotNumber = "32"

grep -i ethernet[0-9]\.pci Test-Full01.vmx |sort
ethernet0.pciSlotNumber = "224"
ethernet1.pciSlotNumber = "256"
ethernet2.pciSlotNumber = "1184"

grep -i pci Test-Full01.vmx |sort
ethernet0.pciSlotNumber = "224"
ethernet1.pciSlotNumber = "256"
ethernet2.pciSlotNumber = "1184"
pciBridge0.pciSlotNumber = "17"
pciBridge0.present = "true"
pciBridge4.functions = "8"
pciBridge4.pciSlotNumber = "21"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge5.pciSlotNumber = "22"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge6.pciSlotNumber = "23"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
pciBridge7.pciSlotNumber = "24"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
scsi0.pciSlotNumber = "160"
scsi1.pciSlotNumber = "192"
vmci0.pciSlotNumber = "32"

[systimax]

Did you ever find a resolution? I have the same problem.

thanks

[dirch201110141]

Grr as well as bump. Same problem also.

As a sidenote when fiddling around with nic's they can sometime "disappear" but can be shown again with the KB:

VMware KB: Removing hidden or ghosted devices from a Windows virtual machine

ye olde...

1. set devmgr_show_nonpresent_devices=1
   
2. devmgmt.msc
3. Shown hidden devices

Ooops: There seems to be a description and some solutions here: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=102007...

I'll try them out with my win2008r2 box.

[jmedd]

We also had this same issue with deploying VMs from Windows 2008 R2 SP1 templates with multiple NICs, specifically NICs of type vmxnet3. Installing the Windows hotfix for 2008 R2 SP1 mentioned in the VMware KB article resolved the problem.