Recently in an internal discussion and lurking through the Veeam Forums, the VMXNET3 virtual adapter came up in regards to its behavior when a MAC change occurs. The VMXNET3 adapter is one of the new paravirtualized devices that are part of the vSphere compliment of technologies.
The behavior in question is that when a Windows Server 2008 or Windows 7 virtual machine is cloned or otherwise incurs a change to the MAC address; the virtual machine will re-enumerate the Ethernet interface. This also happens when using Veeam Backup and Replication’s SureBackup functionality. While I’ve historically been a fan of the VMXNET3 interface, everyone should be aware of this behavior. There are limitations with VMXNET3, such as it not being supported for use in the VMware Fault Tolerance (FT) virtual machine configuration for all versions of vSphere.
The re-enumeration of the Ethernet interface will make it appear still as a VMXNET3 interface, but in the operating system; it will become the next in sequence. For a virtual machine that is created with the default option of selecting an automatically assigned MAC address, the network interface will show up as shown in the figure below if the MAC address changes:
This is all too familiar as many virtualization professionals had this happen when performing physical to virtual conversions, as well as the upgrade that we may have performed going to VMXNET3 from a previous adapter type. Because of this behavior of the adapter, VMware has published this KB article recommending the use of the E1000 adapter type for templates using Windows Server 2008 or Windows 7. If the virtual machine has a custom-defined MAC address, most of these issues do not occur; but this isn’t really a practical solution.
This is just the case when a virtual machine that is launched within SureBackup has an automatically configured MAC address, the virtual machine may not respond correctly to this new environment. The primary observation in most situations is that the guest virtual machine will enumerate the additional network interface (as shown above) and it will not retain any of the networking configuration options that were part of the source virtual machine. This means that the interface will boot up requesting a DHCP address and not have the static IP address configuration that was previously assigned. This doesn’t apply to the other virtual network adapter types (such as E1000 or VMXNET2) or other operating systems such as Windows Server 2003.
For the same virtual machine that was shown above, it receives a new MAC address in the automatic configuration. This is due to how the VMXNET3 interface enumerates itself in Windows. The VMXNET3 device shows its enumeration in the Windows Device Manager as shown below:
This corresponds to its location in the NetworkCards hive of the registry. Basically, each time a new network card interface is enumerated in the operating system; they are displayed here as well. Here is where these IDs are enumerated in the registry:
While all of this is the rather standard experience that we have gone through in cloning a virtual machine or related tasks, it can impact the SureBackup feature of Veeam Backup and Replication 5. In this forum thread, a Veeam user highlighted a situation where using VMXNET3 can impact the SureBackup functionality. Anton Gostev, a product manager at Veeam, points out that the 5.0.1 release of Veeam Backup and Replication will have a workaround.
Update: Version 5.0.1 has been released. Be sure to update previous versions to the latest release.