# chown nobody:kvm /dev/shm/looking-glass
or change user qemu runs as via config to something else, like a dedicated qemu user.
Hmm, I can’t seem to figure it out. I’ve tried both approaches but I’m still getting the permission denied error.
# chmod 777 /dev/shm/looking-glass temporarily,
if it works then there’s some user mismatch between qemu process and ownership of the file which you need to fix (don’t doing chmod to 777 to fix it, it’s a security issue to let everyone access it).
You can also try the previous version with the original setup via ivshmem-server.
I really appreciate your help. Using 777 was one of the first things I tried, but it didn’t change anything. I seem to be able to get a little further using the a9 build, but now I’m getting this error:
Error starting domain: internal error: process exited while connecting to monitor: 2018-01-05T08:07:48.977828Z qemu-system-x86_64: -device -device: Could not open ‘ivshmem-doorbell,chardev=ivshmem,vectors=1’: No such file or directory
I’m sure this must be something minor that I’m just not “getting”.
Edit: Nevermind, I’ve figured it out. I accidentally had two copies of
<qemu:arg value='-device'/> listed in the virsh file. Silly mistakes!
How do define the ivshmem-doorbell device?
DId you start ivshmem-server beforehand?
As an example, I have this in my domain XML:
<qemu:arg value='-chardev'/> <qemu:arg value='socket,path=/tmp/ivshmem_socket,id=ivshmem_socket'/> <qemu:arg value='-device'/> <qemu:arg value='ivshmem-doorbell,chardev=ivshmem_socket,vectors=8'/>
And start the ivshmem-server like so:
sudo -u nobody ivshmem-server -p /tmp/ivshmem-server.pid -n8 -l32M && sudo chown nobody:kvm /tmp/ivshmem_socket && sudo chmod 770 /tmp/ivshmem_socket
any ideas why permissions to /dev/shm/looking-glass files may change (pr even it disappears) after reboot? I’m experiencing this on regular basis and can’t find a root cause.
The filesystem mounted on
/dev/shm/ is a RAM disk and therefore loses its contents on reboot or power off.
df /dev/shm will show you that
tmpfs filesystem, which is the point here, that frames are stored in this shared RAM area (/dev/shm/looking-glass) so frames can be transfered quckly/
ok, so any suggestion how should I set it up so I won’t have to recreate the file / reset permissions after each reboot?
You see above your post how I have set it up, though as I use alpha9 version I still start the ivshmem-server manually and then correct permissions to the socket file after it has been created.
I don’t know how in your case the
/dev/shm/looking-glass file is created, ideally the correct permissions would be set on creation of that file. You can try:
$ sudo -u nobody touch /dev/shm/looking-glass && sudo chown nobody:kvm /dev/shm/looking-glass && sudo chmod 770 /dev/shm/looking-glass
Or just follow gnifs desscription here
I managed to fix this problem just now by modifying the apparmor settings. It turned out qemu didn’t have proper permissions set in there. Whoops.
I added these two lines
and restarted the process, now it works. Fantastic!
I hate to drag the controversy into the room, but I am only beginning to understand the basic properties of IO and kernel level communication on a machine. So I pose a simple question: how badly will the latest Intel “meltdown” patches affect the overall performance of Looking Glass when employing Intel hardware? Perhaps my approach to this is incorrect, and the CPU will have no bearing on the frame-buffer manipulation happening–but I also imagine that there is a ton of IO work going on below the surface using Looking Glass. Thanks ahead of time!
I’ve managed to set up Looking Glass on my rig with the following specs:
CPU: Ryzen 7 1800X
RAM: 32GB 2400MHz
Host OS: Fedora 26
Host GPU: NVIDIA GTX 1080
Guest GPU: NVIDIA GTX 1080Ti
I’ve allocated an entire CCX to the Guest VM along with 8GB of ram, and am running the looking glass client with options
-s -a -k. It works and I am able to access my VM, but it runs very slow. the FPS counter reads 59.9 at all times, but the UPS counter reads 19.9. Does anybody know where the bottleneck could be?
UPDATE: Disabling VSync in the game I was playing (Rocket League) brought UPS up to 60. Noice.
Is someone else beeing affected of broken sound when starting looking glass?
yeah, I’ve followed the tutorial. But the thing is the file disappears after reboot(I think) sometimes or the permissions get changed (so in short - everything works once I set it up, then after reboot it doesn’t and I need to adjust permissions / create file again). Not sure why. But anyways as the permission change in predictable manner I’ll simply add user to a group that has access when the change happens (if I recall correctly the group gets changed to quemu).
The disappearing file will be a bit trickier to handle, but luckily it is rare.
does anyone have any issues getting the lookingglass client on windows starting up at startup. I can manually run the exe no problem but when I add it to the run key in the registery, shell-startup, or task scheduler I get the following output:
[I] CaptureFactory.h:83 | CaptureFactory::DetectDevice | Trying NvFBC
[E] NvFBC.cpp:68 | Capture::NvFBC::Initialize | Failed to load the NvFBC library: 126 - C:\WINDOWS\System32\NvFBC64.dll
[I] CaptureFactory.h:83 | CaptureFactory::DetectDevice | Trying DXGI
[E] DXGI.cpp:163 | Capture::DXGI::Initialize | DuplicateOutput Failed: 80070005
[E] CaptureFactory.h:92 | CaptureFactory::DetectDevice | Failed to initialize a capture device
Unable to configure a capture device
Press enter to terminate…
any reason why I am getting this output?
Do get a login screen after booting Windows? It works fine for me when I have a shortcut to LG in
But I also disabled login screen via
netplwiz and disabled UAC (which may be a security issue for you).
Hey thanks for the great work everything is running smooth but i cant figure out how to uncap from 60 fps.
Tried with -o opengl:vsync=0 but it did not have an effect.
What am i missing?
Did you make sure that there’s no vsync on in the VM, i.e. in nvidia settings or ingame. If that doesn’t work you can try disabling the compositor or configure vsync for it.
nvidia settings vsync is globally off and compton is running at 165hz now and was set to 0 before no changes here, kinda confused right now were the cap is coming from.
I even ruled out that the guest hz somehow cap by switching from hdmi to dp.
Host 1060 and Guest 1080ti both at 1440p
Where do you see the 60 FPS cap? If the hosts refresh rate is 165 Hz and you enable fps overlay in client the FPS number in the corner of client should be ~165, which is the case for me.