E1000 is the adapter type you get by default from old templates and from guest operating systems vSphere does not recognise. VMXNET3 is the paravirtualised one: it offloads more work to the host, handles higher throughput, and costs less CPU. Swapping the two takes one PowerCLI line — and one piece of preparation inside the guest that is the actual reason people find this page twice. Newer Windows templates default to E1000E instead; everything here applies to it unchanged, and the bulk filter at the end catches both.
Connect and look at what is there
PowerCLI C:\> Connect-VIServer
Server[0]: 192.168.100.70
If PowerCLI is new to you, the same connection pattern drives enabling SSH on every host in a cluster.
PowerCLI C:\> get-VM "vm-app-01" | get-Networkadapter
Name Type NetworkName MacAddress WakeOnLan
Enabled
---- ---- ----------- ---------- ---------
Network adapter 1 e1000 pg-app 00:50:56:00:00:00 True
Change the adapter type from E1000 to VMXNET3
PowerCLI C:\> get-VM "vm-app-01" | get-Networkadapter | Set-Networkadapter -type Vmxnet3
Confirm
Are you sure you want to perform this action?
Performing the operation "Setting Type: Vmxnet3" on target "Network adapter 1".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
PowerCLI C:\> get-VM "vm-app-01" | get-Networkadapter
Name Type NetworkName MacAddress WakeOnLan
Enabled
---- ---- ----------- ---------- ---------
Network adapter 1 Vmxnet3 pg-app 00:50:56:00:00:00 True
Add -Confirm:$false to skip the prompt when you are doing this in bulk.
The VM has to be powered off. The adapter type is not editable in the vSphere Client while the VM runs, and Set-NetworkAdapter -Type against a powered-on VM either fails outright or — depending on the vCenter and PowerCLI version — is accepted and then does nothing until the next full power cycle. A guest reboot is not enough; the virtual hardware only changes when the VM is genuinely powered off and back on. Do it powered off and you always know what state you are in.
The MAC address and port group survive the change
The MAC address is unchanged. Compare the two listings: 00:50:56:00:00:00 before and after. That matters more than it looks — DHCP reservations, license bindings tied to the MAC and firewall rules keyed on it all survive the swap. This is the reason to change the type rather than delete the adapter and add a new one, which is how a lot of people do it and how they lose the MAC. (If you are stuck with delete-and-re-add, set the new adapter's MAC to Manual and paste the old address before you power on.)
The port group is unchanged too, so the VM comes back on the same network.
What actually breaks: the guest sees a new NIC
This is the step the one-liner does not do for you. The guest operating system does not see an upgraded card — it sees the old one vanish and an unfamiliar one appear.
- Windows creates a new network connection with default settings. A statically configured IP address goes with the old adapter, which is still in the registry as a hidden device holding that address. You get "The IP address 192.168.x.x you have entered for this network adapter is already assigned to another adapter" when you try to set it on the new NIC. Show the ghost with Device Manager's View → Show hidden devices and uninstall the greyed-out adapter. (Broadcom's KB covers it.) On Windows 7 / Server 2008 R2 and earlier that view does not reveal non-present devices, so run
set devmgr_show_nonpresent_devices=1in an elevatedcmdand startdevmgmt.mscfrom that same prompt. - Linux usually renames the interface, because systemd's predictable names are derived from the device's PCI slot and the VMXNET3 device does not land in the E1000's slot. An
ens32(or an oldereth0) typically comes back asens160on hardware version 13 and later, orens192on older VMs — Red Hat explains the mapping. Anything naming the old interface — an ifcfg file, a netplan or NetworkManager profile, a firewalld zone, a static route — silently stops applying.
So: note the IP configuration before you change anything, and plan for a console session rather than SSH for the first boot afterwards.
The VMXNET3 driver: VMware Tools on Windows, in-kernel on Linux
VMXNET3 is a paravirtualised device, and on Windows nothing in the box drives it: the driver arrives with VMware Tools, so a Windows guest without Tools comes up with no working network at all after the change. Install or update Tools first, while the machine still has E1000 and a working connection.
Linux is the case people get wrong in the other direction. The vmxnet3 module has been in the mainline kernel since 2.6.32 and ships in every current RHEL 9, AlmaLinux 9, Rocky Linux 9 and Ubuntu kernel. open-vm-tools is worth having for the guest agent, quiesced snapshots and IP reporting — but it is not what provides the NIC driver.
Doing it in bulk
The same Get-Cluster | Get-VM pattern drives checking disk latency for every VM. Find every E1000 adapter in a cluster:
Get-Cluster "Cluster-01" | Get-VM | Get-NetworkAdapter | Where-Object {$_.Type -eq "e1000" -or $_.Type -eq "e1000e"} |
Select-Object @{n="VM";e={$_.Parent}}, Name, Type, NetworkName
Then change them to VMXNET3, powered-off ones only:
Get-Cluster "Cluster-01" | Get-VM | Where-Object {$_.PowerState -eq "PoweredOff"} |
Get-NetworkAdapter | Where-Object {$_.Type -like "e1000*"} |
Set-NetworkAdapter -Type Vmxnet3 -Confirm:$false
Verify it came back
On the vSphere side, re-run the listing and confirm Vmxnet3 with the same MAC. In the guest, on Windows Get-NetAdapter | Select Name, InterfaceDescription, Status should show a "vmxnet3 Ethernet Adapter" that is Up; on Linux ethtool -i ens160 should report driver: vmxnet3 and ip -br a the address you noted. If it does not come back, roll back with the VM powered off:
Get-VM "vm-app-01" | Get-NetworkAdapter | Set-NetworkAdapter -Type e1000e -Confirm:$false
Do the inventory first and keep it. It is both your worklist and your record of which VMs to check after the next boot — and on a VM whose network does not come back, the answer is almost always one of the two guest-side problems above rather than anything on the vSphere side.
