Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experimental Steam Image Feedback #63

Open
descention opened this issue May 3, 2023 · 3 comments
Open

Experimental Steam Image Feedback #63

descention opened this issue May 3, 2023 · 3 comments

Comments

@descention
Copy link

I wanted to start some discussion around the usability of the Steam image. I understand it's experimental and want to provide feedback and maybe gather some more information.

Usability

An active workspace eventually expires, which causes the data to clear along with it. I completely understand this can be a good default for images with less of an initial setup.

It would be useful to suggest admins set keepalive_expiration_action to stop instead of the default delete for whatever groups will be using the image. This could be a quick fix for users to keep the workspace from being deleted automatically. I'm using it currently and that one change is making it a huge difference.

Performance

I am grateful for the note about seccomp, as otherwise I would not have been able to use the image.

I couldn't get my AMD GPU forwarded in Portainer but I think that's on me. Until I figure that out, I'll probably stick with testing some CPU bound 2D games. I haven't tried using it for Remote Play yet but I expect it'll work well. I upped the cpu and ram and am getting 33ish fps through the steam store. 60 fps with VVVVVV.

Network and disk usage look to be on par with the ISP/disk I'm hosting the workspace on, almost looks like bare metal stats when downloading a game.

Persistent Volumes

If Remote Play is the intended use, I think a recommendation for a profile path is needed at the minimum. This would ideally prevent having to sync with a pin on each new instance for the same user.

What is recommended for an image that has multiple places data is going to be stored? Any single game save could be in one of a dozen places the developer decides to put it. Does it make sense to store the entire user and steamdata directories (if steamdata isn't already under the user path, I didn't check yet)?

By default, you're redownloading the Steam app update, logging in, and downloading games every time you create the workspace. I think the notes need to be expanded to include some recommended volume mappings. I did try making a snapshot after the initial download of the client and that works well to reduce initial loading time till login.

Final thoughts

This is to get some discussion going for the future use of the image. I couldn't find any other discussion or feedback besides troubleshooting. I'm looking forward to testing it more.

@j-travis
Copy link
Contributor

j-travis commented May 9, 2023

Thank you for the feedback.

Usability & Persistence

I think using a persistent profile https://kasmweb.com/docs/latest/guide/persistent_data/persistent_profiles.html#persistent-profiles , will go a long way to easing some if the usability concerns. Persistent profiles work by storing the users home directory outside of the container so that it can be mapped in to subsequent session. By convention most apps will store the users application configuration/ documents etc somewhere within the home directory. Steam is the same.

Simply enabling the persistent profiles means your steam login , settings, game downloads etc will not need to be re-configured when you create a new session , regardless of if you have the session stopped or deleted.

Beyond the persistent profiles, you may consider using the generic Volume Mapping feature (https://kasmweb.com/docs/latest/guide/persistent_data/volume_mapping.html#volume-mapping) to store steam games outside of the profile (e.g /mnt/steamapps . This might be useful if you wanted multiple images to reference the same steam library, or maybe you wanted to access the library directly from your host. You likely wouldn't be able to access the library at the same time, but it may be useful in certain testing scenarios.

Performance

I cant speak to portainer, but new with Workspaces 1.13, we included the ability for graphics acceleration with Intel and AMD GPUs integrated and discreet GPUs via DRI3. You'll want to read up about that here: https://kasmweb.com/docs/latest/how_to/manual_intel_amd.html#dri3

You shouldn't really need to involve portainer. In-fact I recommend you dont.

NVIDIA gpus are best supported via our virtualGL integration (https://kasmweb.com/docs/latest/how_to/gpu.html)

For NVIDIA/VirtualGL, I've created some notes on getting certain games (including vullkan support) running in the following threads:

With DRI3, you shouldnt need any of the convoluted configurations for the steam games, it should just work

@tehmessiah75
Copy link

What about creating a container with an image of the Steam OS or is that what this is?

@nanospearing
Copy link

I am grateful for the note about seccomp, as otherwise I would not have been able to use the image.

The image also needs to have the privilege set to true in order to fix the "User namespace requirements" error. I have a separate issue that made note of this. #103

I hope this helps anyone in the future looking for a way to fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants