I recently installed Windows 10 for my gaming VM and discovered that my microphone was no longer working. All the drivers were properly installed and sound worked fine, but there was nothing coming from the microphone.
My gaming VM uses a Sabrent USB External Stereo Sound Adapter model AU-MMSA passed through for sound. This was most perplexing because it worked in other OSes, but not Windows 10.
After much digging I finally found this youtube video which outlined the problem: Microphone permissions to the system. The hybrid that Windows 10 is between Store apps / permissions and regular desktop apps reminds me of Windows ME. An unholy union.. terrible.
At any rate, the fix is to grant the system permission to use its own microphone, un-granting it first if necessary.
Go to Start / Settings (little gear icon in bottom left) then search for Microphone Privacy Settings. Click the big Change button beneath “Microphone access for this device is on” at the top of that screen. Change the toggle to “off”, then change it back to “on” again. This fixed my microphone.
I started this blog four years ago to document my highly technical adventures – mainly so I could reproduce them later. One of my first articles dealt with GPU passthrough / virtualization. It was a complicated ordeal with Xen. Now that I’ve switched to KVM (ProxMox) I thought I’d give it another go. It’s still complicated but not nearly as much this time.
To get my Nvidia GTX 1070 GPU properly passed through to a Windows VM hosted by ProxMox 5 I simply followed this excellent guide written by sshaikh. I will summarize what I took from his guide to get my setup to work.
- Ensure VT-d is supported and enabled in the BIOS
- Enable IOMMU on the host
- append the following to the GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub
- Save your changes by running
- Blacklist NVIDIA & Nouveau kernel modules so they don’t get loaded at boot
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "blacklist nvidia" >> /etc/modprobe.d/blacklist.conf
- Save your changes by running
- Add the following lines to /etc/modules
- Determine the PCI address of your GPU
and look for your card. Mine was 01:00.0 & 01:00.1. You can omit the part after the decimal to include them both in one go – so in that case it would be 01:00
- Run lspci -n -s <PCI address> to obtain vendor IDs. Example :
lspci -n -s 01:00
01:00.0 0300: 10de:1b81 (rev a1)
01:00.1 0403: 10de:10f0 (rev a1)
- Assign your GPU to vfio driver using the IDs obtained above. Example:
echo "options vfio-pci ids=10de:1b81,10de:10f0" > /etc/modprobe.d/vfio.conf
- Reboot the host
- Create your Windows VM using the UEFI bios hardware option (not the deafoult seabios) but do not start it yet. Modify /etc/pve/qemu-server/<vmid>.conf and ensure the following are in the file. Create / modify existing entries as necessary.
- Install Windows, including VirtIO drivers. Be sure to enable Remote desktop.
- Pass through the GPU.
- Modify /etc/pve/qemu-server/<vmid>.conf and add
hostpci0: <device address>,x-vga=on,pcie=1. Example
I received the dreaded code 43 error after installing CUDA drivers. The workaround was to add hidden=1 to the CPU option of the VM:
Blue screening when launching certain games
Heroes of the Storm and Starcraft II would consistently blue screen on me with the following error:
The fix as outlined here was to create /etc/modprobe.d/kvm.conf and add the parameter “options kvm ignore_msrs=1”
echo "options kvm ignore_msrs=1" > /etc/modprobe.d/kvm.conf
Update 4/9/18: Blue screening happens to Windows 10 1803 as well with the error
System Thread Exception Not Handled
The fix for this is the same – ignore_msrs=1
Give as many CPUs as the host (in my case 8) and then enable NUMA for the CPU. This appeared to make my GTX 1070 perform better in the VM – near native performance.
I recently came across the need to reboot my Windows 10 workstation remotely. I couldn’t RDP into the box – it would stay stuck on the disclaimer splash screen. There was an OK button but it did nothing when clicked.
My solution was to initiate a reboot command from another Windows PC on the same network as my Windows 10 workstation. I figured out how to do so thanks to this article.
To remotely reboot yourself, log onto another Windows box and open up a command shell with an account that has administrative permissions on the machine you want to reboot. Then, issue this command:
shutdown -r -f -m \\<remote machine name> -t 30 -c "<message>"
The above command forces a reboot command (shutdown -r -f) on the remote machine (-m \\machine name), causes a countdown timer for the number of seconds specified (-t 30) and displays a message on the screen (-c “message”).
It solved my issue and was pretty easy to do. Handy.