4 ms·
It can be done with a bit of work using QEMU/libvirt. The Arch Linux wiki has a good guide for doing it. Not that it’s a pretty solution always…
by kipari 9y ago
It can be done with a bit of work using QEMU/libvirt. The Arch Linux wiki has a good guide for doing it. Not that it’s a pretty solution always…
- blibble 9y agothese days it works out of the box on debian stable run virt-manager, create vm, select your graphics card, and it boots
- deleted 9y ago[deleted]
- stryk 9y agowhich gpus are easier to work with in this scenario, amd or nvidia?
- ymse 9y agoThe two parent posters are probably talking about PCI passthrough, in which case it does not really matter. The virtual machine gets the entire GPU and runs the driver. It also needs a dedicated monitor, keyboard and mouse. However Xenserver (and VMware) supports GPU sharing between multiple virtual machines, essentially GPU virtualization. Both Nvidia and AMD have custom solutions for this. I believe this is what the ancestor comment is using on Xenserver. There is work-in-progress support for GPU sharing in Linux KVM as well, although currently I think it's restricted to Intel. If you're interested in that, I would recommend going with AMD, since they maintain a high-quality driver in Linux itself (unlike Nvidia who only maintains a proprietary out-of-tree driver), and thus is much more likely to be supported by KVM.
- tjoff 9y agoI might be outdated, but GPU virtualization does not allow you to use your display outputs on your graphic card. So for a workstation it isn't going to work as you would have to use another machine (sure, it could be a thin client) to remote desktop (introducing lag I wouldn't want on a worksation) to be able to get any video output. I also believe this requires AMDs or nVidias pro-line graphics cards. So I also used PCI passthrough. I have two GPUs that I pass through meaning that I can run two virtual machines with proper graphic cards (and then regular VMs as I please). The idea was that instead of dual-booting between two machines I run them both at the same time. To switch between them I just select another input on my monitors. Unfortunately though, it is not that simple. This gets easier for every year and it was about 2 years since I last played with this and setup my workstation so things could have changed a bit. But even for PCI passthrough you have to be very careful selecting your GPU, motherboard and CPU. The drivers need to play along and the CPU with motherboard need to be able to isolate everything adequately. Whether AMD or nVidia is best is/was up to debate, each GPU generation has its own quirks. For CPU you ideally you wanted a i7 or a non-entry-level Xeon to be as safe as possible, this is not a requirement but it is very possible that with a "regular" CPU you might not be able to pass through the devices you need to get it to work. More here: http://vfio.blogspot.se/2015/10/intel-processors-with-acs-support.html http://vfio.blogspot.se/2015/10/intel-processors-with-acs-su... Bottom line, it can work great but it is a lot to setup and even if you do your research you might end up in a situation where it just doesn't work. Oh, and the hypervisor you use might screw you, removing the very features you depend on.
- simcop2387 9y ago> I might be outdated, but GPU virtualization does not allow you to use your display outputs on your graphic card. So for a workstation it isn't going to work as you would have to use another machine (sure, it could be a thin client) to remote desktop This may change now with looking Glass giving a fast way to share the frame buffer between host and guest, https://github.com/gnif/LookingGlass https://github.com/gnif/LookingGlass
- tjoff 9y agoVery cool :) Something like that would be very appealing (from a user experience, security I wouldn't now) in Qubes OS.
- simcop2387 9y ago> The two parent posters are probably talking about PCI passthrough, in which case it does not really matter. Not quite, Nvidia actually forbids the use of their consumer level cards being used this way and actively tries to deter it by detecting the use of a hypervisor in the drivers and refusing to initialize the card. There are ways to either work around or defeat this detection, either by using patched drivers that remove the check or by. Having the virtual machine hide it's presence from the guest system which can have a performance impact. AMD does not try to prevent such uses of their consumer level cards and are more likely to work out of the box.
- deleted 9y ago[deleted]