I beg to differ, there is zero risk for anti-cheat triggers, spice just feeds input to the virtual PS/2 controller, which Windows sees as a bog stock standard PS/2 compatible mouse. You’re more likely to trigger “anti-cheat” with a USB hub passed through as there is no way for Qemu to filter out strings that may give hints to the fact that it’s a virtual device.
IIRC there are a few anti-cheats that pick up on spice now. I could be mistaken though.
It’s impossible unless they are detecting the QXL VGA device. Even still SPICE simply feeds input to the I8042 controller, which is a standard part of every PC on the planet.
I run qemu outside of libvirt so I don’t have to attach the QXL device to the guest, spice is completely isolated from the guest, it is impossible for the guest to be aware of it.
it may be qxl related then, because blizzard and battleye both seem to have the usual suspects pretty angry with losing their VMs recently, and everyone is blaming spice
either way evdev passthrough should achieve essentially the same thing.
It must be, because I use it daily and play PUBG which uses BattlEye.
Thats fine until you start running a Linux Guest and a Windows Guest with LG running VM->VM. evdev capture can not handle this scenario.
good to know, hadn’t gotten around to testing it myself yet.
I have been banned for playing hearthstone on WINE, before though
do… do people do that?
not an edge case I had considered
I do that :). TR is such a powerful platform its stupid to dedicate it to a desktop environment only.
The actual host spins up 6 VMs (web-dev, asterisk, bareos, gitlab, windows, linux workstation), using OpenVSwitch to VLAN tag them keeping them isolated from the “Unsecure” network which the Windows guest runs on. My workstation is a Guest with a VEGA passthrough, and Windows is a NVIDIA passthrough.
are you just running a headless hypervisor/homelab type thing?
I knew a few folks that did that on xen/esxi way back when
Essentially, I used to run XEN and dreamed of the day I could run my workstation on the same machine. Now that day is here, and I do just that. The experience is exceptional, being able to reboot VMs independently of each other (except for the vega bug) and keep on working away.
Ie, windows does an update, so I just push Looking Glass onto another workspace while I keep chatting with my mates on TS which is running in the Linux guest.
I dedicate 4 cores to windows, and 4 to my workstation, and it never misses a beat. I export the underlying filesystem to the linux guest as a NFS share, so the guest doesn’t have to worry about ZFS, etc…
makes sense, and yeah hw virt has definitely come a long way in just a few years.
fun fact: you can expose a zfs vdev as a block device if you want
there are people getting quadro passthrough working on bhyve right now, as soon as the wrinkles are ironed out on that I really want to set up something similar
Yes, I am aware of this, which is where the rootfs lives, but /home is mounted as a NFS share, making it easy for backup/snapshots, etc.
Left: three machines, the host, a remote server, and my backup VM.
Middle: Looking Glass + PUBG
Right: webtask.io project I am working on at current.
The main reason to run the workstation seperate from the host, is security. Since I do a ton of development, I can not risk a stray command, rogue script, or bad bit of code, blowing away the other VMs. The worst the Linux guest can do, is screw itself.
ah, yeah that’s a good idea
Oh, and this has also cut my power bill down by 40%, since I was able to deprecate the office server and integrate it all into the one machine.
That’s great! Something people forget about a lot is the power bill.
For my understanding regarding LG: are keyboard and mouse redirections made through the Spice server set on the VM?
Oh, of course! Forgive me. Between the Linux host and the Linux guest, I got confused and lost sight of which step I should follow. After adding the shmem device in XML, I got the server running correctly in Windows.
In Linux, however, I’m getting an error in the client:
[I] main.c:692 | run | Looking Glass ()
[I] main.c:693 | run | Locking Method: Atomic
[I] main.c:686 | try_renderer | Using Renderer: OpenGL
[I] main.c:775 | run | Using: OpenGL
[E] main.c:635 | map_memory | Failed to stat the shared memory file: /dev/shm/looking-glass
[E] main.c:860 | run | Failed to map memory
Maybe worth mentioning: For these instructions:
It is suggested that you create the shared memory file before starting the VM with the appropriate permissions for your system, this only needs to be done once at boot time, for example (this is a sample script only, do not use this without altering it for your requirements):
chown user:kvm /dev/shm/looking-glass
chmod 660 /dev/shm/looking-glass
There is no ‘kvm’ user in unraid, so I did chmod 777.
Edit: For reference, I’m using the A11 client. I also tried A10 and it gives the same result.
Are you trying to run VM->VM? If so read the
README.md file in the
Answered my own question.
Tried the evdev method + VFIO drivers for mouse/keyboard: works great with LG!!
Never enjoyed CTRL-CTRL that much