Here’s a great tutorial for vim-cmd if you haven’t had experience with it before by my friend, Steve Jin: www.doublecloud.org/2013/11/vmware-esxi-vim-cmd-command-a-quick-tutorial/
This is a real-world situation I got myself into when I tried connecting to my client VM and found a BSOD that looked like this:
It’s pretty obvious that the reason for the crash is the USB stick that’s plugged in from the usbuhci.sys line in the blue screen. Since I tunnel into my client VM via SSH and VNC, the easiest way for me to shutdown my VM and remedy this issue is through vim-cmd. This only works if you have SSH allowed onto your ESXi host or if you are connecting to the host with the VMware CLI or vMA or whatever they’re calling it these days. I have the former.
The first thing I do after logging into the ESXi host as root is run:
vim-cmd vmsvc/getallvms
I need to know which one of my VMs is the one to manage. I get this:
Vmid Name File Guest OS Version Annotation 1 windows7 [BIG_DISK] windows7/windows7.vmx windows7_64Guest vmx-07 3 thimble [BIG_DISK] thimble/thimble.vmx ubuntu64Guest vmx-08 4 chunli [Datastore 2] chunli2/chunli2.vmx ubuntu64Guest vmx-08 5 zangief [Datastore 2] zangief2/zangief2.vmx ubuntu64Guest vmx-11
With this information, I know that it’s VM 1, so I power it off by running:
vim-cmd vmsvc/power.off 1
Thinking the USB issue might be a fluke, I try to power the VM back on to see if it will boot.
vim-cmd vmsvc/power.on 1
I see that it starts booting, but as the resolution changes on the VM, my VNC viewer freezes. Since I normally don’t know exactly when it freezes, I didn’t know when I got the BSOD again.
Until I decided to at look at the vmware.log file. This is what I saw there:
2017-10-18T22:27:05.519Z| svga| I125: SVGA disabling SVGA 2017-10-18T22:27:05.545Z| svga| W115: WinBSOD: (20) 'Technical information: ' 2017-10-18T22:27:05.545Z| svga| W115: 2017-10-18T22:27:05.546Z| svga| W115: WinBSOD: (22) '*** STOP: 0x000000D1 (0xFFFFF88000BF2000,0x0000000000000002,0x0000000000000001,0' 2017-10-18T22:27:05.546Z| svga| W115: 2017-10-18T22:27:05.546Z| svga| W115: WinBSOD: (23) 'xFFFFF88004206E49) ' 2017-10-18T22:27:05.546Z| svga| W115: 2017-10-18T22:27:05.557Z| svga| W115: WinBSOD: (26) '*** usbuhci.sys - Address FFFFF88004206E49 base at FFFFF88004200000, DateStamp' 2017-10-18T22:27:05.557Z| svga| W115: 2017-10-18T22:27:05.557Z| svga| W115: WinBSOD: (27) ' 57b37a29 ' 2017-10-18T22:27:05.557Z| svga| W115: 2017-10-18T22:27:05.557Z| svga| W115: WinBSOD: (30) 'Collecting data for crash dump ... ' 2017-10-18T22:27:05.557Z| svga| W115: 2017-10-18T22:27:05.573Z| svga| W115: WinBSOD: (31) 'Initializing disk for crash dump ... ' 2017-10-18T22:27:05.573Z| svga| W115: 2017-10-18T22:27:07.547Z| mks| W115: Guest operating system crash detected.
Okay, so I see that my hunch is correct. I guess it’s time I remove the USB device from the VM. So I power off the VM again and open up the vmx file and just start removing all instances of USB.
These are the lines I removed. Don’t worry about breaking anything. The hypervisor will put them back if you need them later. Back up your vmx file before doing it though just in case.
usb.pciSlotNumber = "34" usb.present = "TRUE" usb:1.speed = "2" usb:1.present = "TRUE" usb:1.deviceType = "hub" usb:1.port = "1" usb:1.parent = "-1" usb.autoConnect.device0 = "path:1/1 autoclean:1" usb:0.present = "TRUE" usb:0.deviceType = "mouse" usb:0.port = "0" usb:0.parent = "-1"
After you’ve saved your changes, you’ll need to reload the changes so that ESXi will reread the .vmx file to remove the USB device. You can do this by running this command:
vim-cmd vmsvc/reload 1
Now you’re ready to power on the VM.
vim-cmd vmsvc/power.on 1
The VM powers up and I’m back in business. I just had to figure out the USB issue later. Turned out that I just needed to reconnect the device and reformat it. I haven’t seen the issue come up again.