Escaping from PSOD ‘PF Exception 14’ using PowerCLI

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:

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!

2 thoughts on “Escaping from PSOD ‘PF Exception 14’ using PowerCLI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s