• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Computer parts for virtaulization

dbzlotrfan

n00b
Joined
Apr 17, 2012
Messages
19
I would like to at some point (see fourth bullet point below) replace my CPU (and my motherboard if necessary) and perhaps a second GPU (or replace my current one) for virtaulization - run a native linux distro (like Mint) and run a virtual machine of Windows while passing through a gpu to windows to get near native windows performance.



  • Country: USA
  • Budget: *can't decide at moment* . . .
  • Computer Use: Running Linux (Mint, Ubuntu, or others) natively and run Windows in a virtual machine
  • When I'd buy/build: Sometime by holiday next year . . .
  • Other Notes: No interest in overclocking or watercooling.
  • Parts needed: CPU, motherboard, GPU. I'd probably like to replace the keyboard and mouse as well (gaming oriented)
Current Parts:


Games I'd like to run: See steam games ([URL]http://steamcommunity.com/id/DlfC/games/?tab=all[/URL]) and wishlist: (http://steamcommunity.com/id/DlfC/games/?tab=all) along with probably anything from GOG (that may or may not be on steam). Along with retail discs (either through Wine/PlayonLinux or virtual machine of Windows).
 
Almost all recommendations will need to be reconsidered in a year as the industry moves rather quick.
 
You'll want to make sure your chosen motherboard has field-proven VT-d capability since you are planning to do gpu passthrough. Make sure others have gotten it to work to save yourself hours of potential frustration. A lot of non-server motherboards claim VT-d/IOMMU support, but the BIOS doesn't map the IVRS table correctly.

You can fix the IVRS table via a boot override command to inject the correct IVRS entries. But it's best to use a known, good motherboard that fully supports Intel VT-d or AMD IOMMU.

For your reference, in case it's needed:
http://ubuntuforums.org/showthread.php?t=2254677
 
It would be far easier to run windows natively and linux on a VM
 
Easy wouldn't build up OP's brain muscle in this area of interest. :)
 
You'll want to make sure your chosen motherboard has field-proven VT-d capability since you are planning to do gpu passthrough. Make sure others have gotten it to work to save yourself hours of potential frustration. A lot of non-server motherboards claim VT-d/IOMMU support, but the BIOS doesn't map the IVRS table correctly.

You can fix the IVRS table via a boot override command to inject the correct IVRS entries. But it's best to use a known, good motherboard that fully supports Intel VT-d or AMD IOMMU.

For your reference, in case it's needed:
http://ubuntuforums.org/showthread.php?t=2254677


That's interesting. Is IOMMU working on my system?


Code:
$ dmesg | grep AMD-Vi
[    1.232711] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    1.232713] AMD-Vi: Interrupt remapping enabled
[    1.245161] AMD-Vi: Lazy IO/TLB flushing enabled



$ dmesg | grep IOMMU
[    1.232711] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[   46.405733] [B]vboxpci[/B]: IOMMU found
[ 4139.418098] created IOMMU domain ffff8803cd497ac0
[28678.298244] created IOMMU domain ffff8802fa3560c0



$ dmesg | grep PCI-DMA
[    1.320098] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
 
That's interesting. Is IOMMU working on my system?


Code:
$ dmesg | grep AMD-Vi
[    1.232711] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    1.232713] AMD-Vi: Interrupt remapping enabled
[    1.245161] AMD-Vi: Lazy IO/TLB flushing enabled



$ dmesg | grep IOMMU
[    1.232711] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[   46.405733] [B]vboxpci[/B]: IOMMU found
[ 4139.418098] created IOMMU domain ffff8803cd497ac0
[28678.298244] created IOMMU domain ffff8802fa3560c0



$ dmesg | grep PCI-DMA
[    1.320098] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)


From the output messages above, you should have IOMMU working. Try passing through a device to a VM.
 
Guess I should ask - could I use something like virtualbox or would I have to use some other virtual machine program?
 
You could also try KVM. It's well supported on both Debian/Ubuntu and Red Hat/Centos camps. There is also Xen. KVM and Xen are field proven, open-source hypervisors. Fairly easy to setup too. Together, they have more marketshare (51%+) than VMware.

VirtualBox is good for learning initially. I am not aware of it being used in a large, mission critical production environment.
 
From the output messages above, you should have IOMMU working. Try passing through a device to a VM.

Thank you. USB device handover in Vbox works even without IOMMU. I'm just curious if my VMs benefit from having enabled IOMMU. Like do they run faster or more stable? Or if I handover a USB device, does it run more reliably?

As for video card passthrough, form what I've read, you have to pass control of GPU back-and-forth between Guest & Host, which seems like a pain in the ass?

About IVRS, does this mean anything?

Code:
$ dmesg | grep -i IVRS
[    0.000000] ACPI: IVRS 00000000caba5af0 000F8 (v01  AMD     RD890S 00202031 AMD  00000000)
 
Last edited:
Dedicating/passing NICs and GPUs require IOMMU/VT-d. USB doesn't require it strictly.

To do what OP wants to do - achieve near-native gaming performance on a Windows VM - you need hardware passthrough. Having 2 or more GPUs in the VM host works best in this use case.
 
Dedicating/passing NICs and GPUs require IOMMU/VT-d. USB doesn't require it strictly.

To do what OP wants to do - achieve near-native gaming performance on a Windows VM - you need hardware passthrough. Having 2 or more GPUs in the VM host works best in this use case.

I see, so each OS gets it's own dedicated GPU? One for the Host and one for the Guest?

I have only one GPU and switch back-and-forth between guest & host(s) constantly, so I'll get a black screen until I manually hand over the GPU, and since I'm in full-screen I'll have no GUI until I do?


BTW, the OP's K-series CPU has VT-d disabled.
 
Last edited:
I see, so each OS gets it's own dedicated GPU? One for the Host and one for the Guest?

I have only one GPU and switch back-and-forth between guest & host(s) constantly, so I'll get a black screen until I manually hand over the GPU, and since I'm in full-screen I'll have no GUI until I do?

Correct. Ideally, 1 GPU for host and 1 for VM. 2 monitors or 1 monitor with input toggling.

With only 1 GPU, the VM takes over the monitor completely, until shutdown. Then the host OS GUI returns.
 
Correct. Ideally, 1 GPU for host and 1 for VM. 2 monitors or 1 monitor with input toggling.

With only 1 GPU, the VM takes over the monitor completely, until shutdown. Then the host OS GUI returns.

Thank you. it seems simpler and cheaper to have 2 machines or just dual boot.
 
Last edited:
Back
Top