Today I stumbled upon an issue where I couldn’t power on a particular VM without triggering a PSOD (Exception 14) on the ESXi host the machine was registered on. This article describes the reason for the PSOD and how I solved it using PowerCLI.
First of all, I didn’t have a vCenter Server / vSphere Web Client available and had to reconfigure a VM with extra CPU and memory power. Since I was using vmx-10 virtual machines (vSphere 5.5), I couldn’t edit VM settings through the vSphere Client.
To do this, I used the following PowerCLI command for this task:
Set-VM VMNAME -MemoryGB 8 -NumCpu 4
The command succeeded (yeey!) and I booted up the VM.
Even before Windows welcomed me with a login prompt, I lost my connection with the vSphere Client. Uh-oh..
After some pinging I knew something was wrong with the ESXi host so I went checking the console and was presented with a painful purple screen of death:
- Purple Screen of Death, uh-oh!
I was positive this had to do with the VM I had just powered on, so I guessed it had to do with the way I edited the VM settings (Maybe it configured the number of virtual sockets/cpus wrong or something like that) so I changed the settings back to where they were and retried. BAM! Another PSOD, so I decided to leave the VM powered off for a while.
Now, some hours later I continued my search and found out that Exception 14 is caused by using too many E1000(e) virtual adapters on a single host. Well, if there’s something I try to avoid, it’s using anything else but the VMXNET3 adapter. Discovering this problem was a piece of cake using this KB article by VMware: http://kb.vmware.com/kb/2059053.
The article describes you should use the following PowerCLI command to find out which VMs are using the E1000(e) adapter:
ForEach( $VM in (Get-VM) ) { $VM|Where{ $VM|Get-NetworkAdapter|Where{ $_.ExtensionData -like “*e1000*” } } }
Next, you should edit your VMs by removing the old adapter and creating a new VMXNET3 virtual adapter. I used the following commands to do this, VM by VM (easily turned into a multi-VM script for larger volumes):
$vm = Get-vm VMNAME
Get-NetworkAdapter $vm | Remove-NetworkAdapter
New-NetworkAdapter -VM $vm -Type Vmxnet3 -StartConnected -NetworkName “VM Network“
$vm | Start-VM
Be sure to replace VMNAME and your networkname. Oh, this is to be used with a standard vSwitch. The PowerCLI commands I had to use to link the new adapter to a distributed switch didn’t work, but that’s probably because the vCenter Server was unreachable at the time 🙂
After replacing all virtual adapters and running the ForEach loop to query for E1000(e) adapters, I switched on the VM that caused the PSOD (and it wasn’t even his fault!) and everything is running smoothly now.
I wonder why VMware chose to create new virtual machines with the E1000 adapter as default, instead of the more enhanced VMXNET3 adapter. Most OS’s support this adapter and I didn’t see any issues with it in the field yet that would require using a different adapter.
Thanks for reading!
Life saver! We must have just hit the ‘limit’ as our hosts were going into regular PSOD mode.
LikeLike
Great it helped Jay and thanks for your feedback! =)
LikeLike