Virtual Reality VM: Part 2 – Wireless Conclusion

Virtual Reality VM: Part 2 – Wireless Conclusion


After I had the Virtual Reality VM working for a few hours I noticed something weird was happening.  It didn’t seem to be able to download anything quickly.  I have gigabit internet, and it was taking 2 hours to download a 4GB game.  That should not be.  It took me a bit to discover what was actually causing this issue.  I checked the resource monitor from Windows 10 and discovered I only had 2 CPUs.

That was very strange.  But with only 2 CPUs, the system was struggling to handle all of the hardware allocated to it, especially processing the bandwidth of the downloads.

As can be seen in the background,I had allocated 32 CPUs to the system.  Why were only 2 showing up?  I did have a theory.  I remember reading that Windows 10 Pro has a CPU socket limit.  It is two [1].  Meaning only two CPUs will be recognized.  So a bit of this depends on exactly how the vCPUs are being presented to Windows 10.

To check this, I clicked on edit.

Then I expanded the CPU section and saw the issue.

VMWare is presenting 32 sockets to Windows 10, each with one CPU.  Therefore Windows 10 cuts off all of the sockets after two, and I am left with only two CPUs.  This is very inconvenient.  I’m not sure how best to address this, but maybe a warning during VM creation?  It took a bit of intuition and guess work to figure that issue out.  

In any event, I went ahead and set it to 32.

And now Windows sees all of the CPUs.

From the resource monitor it has two nodes and 16 CPUs in each node.  I think that the first time I fixed this I gave it two sockets and 16 CPUs, I was just demonstrating the issue again here.  That is my best guess for why Windows 10 does 2×16 CPUs, not 1×32 CPUs.


There really isn’t all that much left to do with the Virtual Reality VM.  When I last discussed it, I had it working in a basic sense.  The Vive Pro Eye was working, I played a few rounds of Beat Saber, which I am terrible at.  However, I always hated the long wires between the headset and the server. 

It’s not that the wires were all that difficult to work with, more that they were just a bit annoying.  I found a wireless adapter HTC made [2].  When I first found this kit, it was not nearly as clear whether it worked with the Vive Pro Eye [3].  I ordered it and found something quite surprising.  It used a PCI card to make it work.

Vive Wireless Adapter

A brief overview here may help.  The vive wireless adapter kit from HTC has three components.  First it has a WiGig card [4], then a wireless link [5], and a wireless adapter.  Once all 3 of these are installed, then it should be possible to drop the cords and just use the Vive wirelessly.

I did not know at first I would need a PCI slot for this.  I found another wireless adapter by TPCast [6], which does not need this and uses USB.  This doesn’t list that it supports the Vive Pro Eye though, and I didn’t trust that I could get it to work.  So I decided I would need to find a way to support the PCI slot for it.  

Slimline SAS-4i to PCI slot

When I was attempting to get the Optane drives working, I left one of the Slimline SAS-4i’s unused.  While I was working through all of the failures at the time, I saw a PCI adapter for Slimline SAS-4i.  I figured this was worth a shot.  It did not work.

1.2 TB Intel 750 PCIE SSD

I wasn’t sure if this was an issue with the WiGig card specifically or the converter.  Luckily, I had an old Intel 750 from a few years ago.  I plugged that in to the adapter and it worked just fine.  My best guess here is that the Slimline SAS-4i connects to a storage controller, so it is only capable of processing storage devices.  

I still think this should have a possibility of working. I have seen m.2 wireless cards [6].  However, it could be a result of this being native Slimline SAS-8i with an optane connected and this as the second connection.  Or possibly that the Slimline SAS-8i is attached to the output of a storage controller, whereas m.2 doesn’t include one?  I am simply not sure here, and I haven’t been able to get a great answer from research.  

In any event, it doesn’t appear that this conversion will work.  So I replaced the Solarflare SFN-5122F with the WiGig card.  I am unhappy with that.  Using a PCIE x16 slot for a PCI x1 card is not the best use of resources.  This will probably be the first thing to go if I ever need to reclaim a PCI slot.  That being true, I don’t need the 10G card, I do have x550 10G ports on the motherboard I can use.  They are just lower latency.

After installing the WiGig card, it shows up in VMWare as an Intel Corporation Network Controller

I went ahead and toggled PCI passthrough on that.  For step by step on that, please see the first article on the Virtual Reality VM.  It shows up in the VM edit screen a little odd.  It is listed as the <class> Network Controller.  I think the PCI identification information isn’t being processed well by VMWare.  Not to fret though, it worked in passthrough mode just fine.  I think Intel does a great job at making sure their devices work with VMWare here.

I went ahead and plugged in the wireless link and wireless adapter.  It worked out of the box.  Well done HTC.  I enjoyed my next round of beat saber, I’m still pretty bad at it, but there was no latency or lag.  

Left: Vive Pro with Wireless adapter and battery, Right: Vive wireless link

This is essentially the end of the posts on the Virtual Reality VM.  I have everything installed, all of the systems are working.  The last step here was to insert my activation key for Windows 10.  For that, I just went to settings, searched for activation and select the change product key option.  From there I could just type it in [8].  That is sort of the last thing to do here.  Virtual Reality VM success!

The working wireless adapter on the Virtual Reality VM









Leave a Reply