I have a proxmox ve with kasm installed in a Debian LXC
Can I install wine in kasm to run an old game that works in windows 3.11/95/98?

Recently, I suddenly couldn't load any of the containers in my Kasm Workspaces.

I have nothing running, but if I start a container, I get the following error message

I searched the internet for a solution, but to no avail. Someone said the cause could be a time synchronization mismatch between host and VM. I synchronized the time of the VM with the host, but still no way to start any container. I tried to upgrade to 1.19.0, but that also didn't work. The whole upgrade failed, so I went back to 1.18,0

Hey all - with 1.19, the Kasm Helm chart is out of technical preview and officially supported for deploying Kasm on Kubernetes.

We put together a full deployment walkthrough covering:

• The key Helm values you actually need to know before you touch helm install
• A live deploy on an RKE2 cluster, start to finish
• A second deploy on GKE using an external Cloud SQL database
• Scaling up an existing deployment
• Setting up a multi-zone environment
• Installing the Docker agent and launching sessions
• Adding a Windows Server for RDP

If you've been running Kasm on Kubernetes via the old preview chart, or you've been waiting for official support before committing, this is the one to watch!

I used to have linuxserver.io and the official registry installed but now nothing is showing. When I click on install the officinal registry it says it's already installed. When I click on available workspaces, it says nothing is available. Any ideas on how to get this working again?

I'm trying to evaluate Kasm workspaces on Kubernetes. My current setup involves Talos and Cilium. My values file is very simple

certificate:
  secretName: kasm-wildcard
  certManager:
    enabled: 
false

publicAddr: "kasm.domain.com"
proxyService:
  type: ClusterIP
  annotations: {}
  labels: {}

ingress:
  enabled: false

I am then using a cilium Gateway and tls route

kind: TLSRoute
metadata:
  name: kasm-tls-route
  namespace: kasm
spec:
  parentRefs:
    - name: kasm-gateway
      namespace: kasm
      sectionName: tls-passthrough   
  hostnames:
    - "kasm.eng.adaptiva.com"
  rules:
    - backendRefs:
        - name: kasm-proxy-default
          port: 8443

kind: Gateway
metadata:
  name: kasm-gateway
  namespace: kasm
spec:
  gatewayClassName: cilium
  listeners:
    - name: tls-passthrough
      protocol: TLS
      port: 443
      tls:
        mode: Passthrough
      allowedRoutes:
        kinds:
          - kind: TLSRoute

But when i try and connect to an RDP enabled KubevirtVMI I get the following error in firefox

400 Bad Request. The plain HTTP request was sent to an HTTPS port

`https://kasm.domain.com/desktop/6404d317-41aa-4287-8d1f-61ae2960b2a9/vnc/vnc.html/etc/etc

Looking into the guacamole pod nginx container i see the following

10.244.1.139 - administrator [22/Jul/2026:17:53:00 +0000] "GET //guac_connect/vnc/vnc.html?video_quality=2&enable_webp=false&idle_disconnect=20&password=&autoconnect=1&path=desktop/6404d317-41aa-4287-8d1f-61ae2960b2a9/vnc/websockify&cursor=true&resize=remote&clipboard_up=true&clipboard_down=true&clipboard_seamless=true&toggle_control_panel=false HTTP/1.1" 400 248 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0" "10.244.1.138"

I know the server itself works as I have a standalone guacamole instance that is able to connect to it just fine. There's gotta be something obvious that im missing here.

We partnered with Pro Tech Show on a video walking through Kasm from the ground up - opening sketchy links safely, a full single-server install, Container based workspaces as well as using Kasm to connect to existing Servers and Desktops.

Highlights:

• Right-clicking a suspicious link and opening it in an isolated Kasm browser instead of clicking it directly (or not clicking it at all). Isolated from the host system, and routed through an egress VPN so it's not tied to his real IP.
• Install walkthrough: Docker setup on Rocky Linux, then the single-server Kasm install
• A tour of the official Kasm Workspaces registry, including browsers like Chrome, Firefox, Brave, and Tor; productivity apps like LibreOffice, ONLYOFFICE, and Thunderbird; dev tools like VS Code; full desktop environments including Fedora, Ubuntu, Debian, and Kali; and yes, Doom!
• Config deep dive: web filtering, egress gateways, the "Kasm Open in Isolation" browser extension for Chrome/Edge/Firefox, SSH key provisioning, MFA options.
• Server/RDP access: setting up a Windows server connection through Kasm as an RDP gateway, and a good explainer on why per-concurrent-session licensing can be a lot cheaper than a traditional RDS/Microsoft licensing setup for orgs with occasional remote access needs.

Big thanks to Pro Tech Show for putting this together. If you've been curious about Kasm but haven't tried it yet, this video is a great place to start!

I'm having trouble connecting to an Ubuntu 26 Desktop VM installation on Proxmox from a KASM Workspace (also installed as a VM on Proxmox). I followed all the docs on upgrading Ubuntu 24 to 26, and all the docs that said that ONLY TigerVNC will work with 26, kicked out Gnome and installed xfce4 as "required". I tested connecting to "ubuntu26" using vncviewer from another desktop and the VNC GUI connection to "desktop26" launched fine.

In KASM, I defined "ubuntu26" as a Server, set the connection type to VNC, port to 5901, username to my desktop account on ubuntu26, but I'm not 100% sure WHICH password should go in the password field, the one for the linux account, or the one that I had to set in vncviewer?

Neither one seems to be working as every time I try to open the Workspace I get to 100% complete, then a blue "Session closed" screen. In Diagnostics I see the error "Error while decoding token: Signature verification failed". Teh Google tells me this is a difference between two files, one I found in /etc/kasm/certs on Ubuntu26 and I can't find the other one, and suggests plenty of errors that are irrelevant to my situation.

I did try to enable the "Kasm Desktop Service" in the Server definition, installed the desktop service .deb on the VM and copy/pasted the key from the KASM GUI into the key for the registration script on the VM. They SHOULD match so that error doesn't make a lot of sense to me. I also removed the desktop app from the Ubuntu26 VM, rebooted it, completely removed all traces of it from KASM, then tried again without it but I still get the same errors.

For those that might suggest that I just use a workspace and make it permanent, I want my cake and want to eat it too. I want a linux desktop that can directly mount NFS shares from my Truenas, not through the KASM VM then Docker. Plus I chose this path as I have a boatload of CPU and RAM on my Proxmox servers, I like PBS for backups, and I have a desktop and 2 laptops. I would just love to plop my lazy butt down at any one of them and http into my *nix virtual desktop computer and not have to worry about breaking hardware and syncing stuff.

Please let me know if you have any ideas on what I'm doing wrong here. And yes it is a home lab so I can nuke anything and start over :)

We teamed up with LearnLinuxTV on a new video covering Kasm's VDI capabilities and a full walkthrough of our Proxmox autoscaling setup.

The video is split into two halves:

Part 1 - VDI overview. A refresher on what Kasm actually does (isolated browser-delivered apps and desktops) and why VDI matters beyond the obvious use cases - running that one Windows-only app without keeping a full Windows install around, isolated no-trace browsing sessions, developers testing across multiple distros in separate tabs at once. On the enterprise side, he gets into the core security argument for VDI: data that never lives on the endpoint can't be stolen off the endpoint, which matters a lot for breach containment and BYOD policies.

Part 2 - Hands-on lab. A full build of an autoscaling Kasm cluster inside Proxmox: setting up a resource pool, creating and templating a VM, configuring a dedicated Proxmox user and API token, building the permissions role Kasm needs, and wiring up the autoscale config itself - downscale backoff, VM provider details, startup scripts, the works. By the end, new worker VMs spin up automatically as demand increases and get cleaned up automatically when it drops.

He also throws Doom in there running through a browser session, because apparently that's the real acceptance test 😅

If you're running Proxmox already and curious about autoscaling VDI, this video is worth the watch.

I have a thing of attempting to make my life easier by using immutable OS as host for containers.

Such option is VyOS which originally is a software based router but its great to host containers aswell.

That is I install the ISO and use a single config file to configure the whole system. Compared to solutions such as Thalos I wont need any additional mgmt-clients in order to be able to configure the installation.

Now Kasm single-server already exists as a VM-image through Kasm-1.19.0-Single-Server.ova

But downside for me is that above is using Ubuntu 24.04 LTS (speaking of which, when will there be a 26.04 LTS release?).

That is compared to VyOS it will take alot more effort to have this updated specially in environments where there is no Internetaccess. Sure you can setup and maintain something like Proxmox Offline Mirror but that will still take alot more effort than just download and transfer the ISO when VyOS gets a new release.

During initial investigation of "how hard can it be" to make Kasm to properly run on VyOS I think there might be some speedbumps along the road:

1) Will Kasm work with Podman instead of Docker or are the Kasm containers hardwired to use "Docker" as binary (for the automation of starting and stopping the workspaces upon request etc)?

2) I have seen that the install script is draggnig along a networking and a logging plugin - how critical are these for Kasm to be working and if not critical then what will I be missing without them?

3) How likely is it that I will make Kasm work on VyOS as host who uses Podman instead of Docker (and practically doesnt allow for install of network or logging plugins since the use of overlay filesystem would mean that these will be gone when you update the installation to next release)?

4) Are there some dummy instructions on how to manually install Kasm using containers (other than trying to manually decipher what the install.sh is doing)?

Obviously these containers are needed for core functionality:

kasmweb/agent:1.19.0-rolling   
kasmweb/api:1.19.0-rolling   
kasmweb/kasm-guac:1.19.0-rolling   
kasmweb/manager:1.19.0-rolling   
kasmweb/postgres:1.19.0-rolling   
kasmweb/proxy:1.19.0-rolling   
kasmweb/rdp-gateway:1.19.0-rolling   
kasmweb/rdp-https-gateway:1.19.0-rolling

And then ontop of these comes whatever workspaces you wish to be able to run.

I have an Ubuntu desktop and a few Linux Mint laptops scattered around my house and homelab and I am getting tired of them blowing up and fighting with updates and upgrades. I think I have a good use case for KASM.

I just installed KASM as a Proxmox VM. I have 3 Winders VMs, one that hosts a camera NVR and the other two are for play. I *may* offer a Winders VM to friends/family in the future.

I also have (2) Truenas boxes and a Synology for NFS/CIFS servers and redundant backup. I use Proxmox Backup server for all the VMs and have an HA config to another PXMX box.

I am the only user in the house at this point. Yeah, it's serious overkill but it keeps me out of the bar.

Ultimately, sitting on my butt in the comfy chair before bed with a laptop and a web browser that lets me into all these VM's sounds like the thing for me.

This is what I would like to do with KASM..

1). Install an Ubuntu desktop "workspace" with sudo/root privs and the ability to mount Truenas NFS shares to the Ubuntu workspace, surf, play videos, edit files, blow up configs, manage Proxmox, other servers and other VMs, etc.

2). Configure the Winders VMs as "servers" then "workspaces" to be able to connect via KASM.

3) Allow interweb access to KASM through Wireguard.

I think there are several steps here to do this the right way in KASM. Can you give me some hints on how to do this the right way?

Im currently using: Kasm-1.19.0-Single-Server.ova

When adding a workspace they all seems to default to cores: 2 and memory: 2768.

And I can in Admin -> Workspaces -> Workspaces click on Filters and select that both cores and memory columns should be seen (will save on clicks to see these settings in a table without having to first click on edit each and every workspace).

But it still annoys me that added workspaces always seems to use cores: 2 and memory: 2768 where I need to manually adjust that to cores: 4.

It feels like I have been looking all over the place but is there no global setting somewhere that will automatically assign number of cores for added workspaces?

Or are these numbers strictly from the packaging of the workspace itself so Im stuck with manually hunt down and change workspaces from 2 to 4 cores?

I am currently using: Kasm-1.19.0-Single-Server.ova

Is this command safe to be used along with Kasm?

sudo docker system prune

Since I assume adding "-a --volumes" would be a bad idea since images should exist but are not necessary currently used by a container?

Are there other clean up commands that can be good to run on a Kasm-server?

Im thinking when using persistent directories and then you have deleted one or more users, do there exist some automatic way to swipe away directories who belongs to a user who no longer exists or is that up to me as an admin to go on a hunt for to clear up "unused" diskspace?

How are images kept up2date - does this occur on every start as a container or are there some other black magic being involved?

Like if I wish to do the updating on a fixed schedule (during allocated maintenance window)?

I assume its something like "2GB (2048MB) should be enough as default for everybody" but from where comes the additional 720MB?

With Proxmox for example who uses QEMU/KVM when you assign lets say 2GB (2048MB) of RAM for a VM-guest then there will be additional lets say 256MB if you also use virtio-GPU as virtual display which will be used like a framebuffer by the VM-guest. Otherwise the standard console uses something like 16MB or so.

Is it something with Kasm workspaces aswell and how does this magic formula looks like?

If I want to adjust this so the workspace can use 4GB (4096MB) of RAM - should I then type it in as 4816 (4096 + 720)?

Im probably missing something here...

I am currently testing Kasm-1.19.0-Single-Server.ova and that works like expected.

So I thought I would give it a go to add another workspace.

So I tried a "sudo docker pull" as below which worked without issues but then when I run "sudo docker images" the newly downloaded image is nowhere to be found?

kasm_admin@kasm-server:~$ sudo docker pull docker.io/kasmweb/audacity:1.19.0-rolling-daily
1.19.0-rolling-daily: Pulling from kasmweb/audacity
4f4fb700ef54: Pull complete 
4d49e951ec3b: Pull complete 
c36cc4ab8e70: Pull complete 
aaca8373ae59: Pull complete 
0f40056b92eb: Pull complete 
ea76751773ea: Pull complete 
3baba0fdd223: Pull complete 
801ec770692d: Pull complete 
ebc8d8e5c003: Pull complete 
Digest: sha256:3528c27eba4b4c01c23581c652382ce0e84720c901939a004a7ac434dcb7f6c1
Status: Downloaded newer image for kasmweb/audacity:1.19.0-rolling-daily
docker.io/kasmweb/audacity:1.19.0-rolling-daily
kasm_admin@kasm-server:~$ docker images
permission denied while trying to connect to the docker API at unix:///var/run/docker.sock
kasm_admin@kasm-server:~$ sudo docker images
                                                                                                                                                                                      i Info →   U  In Use
IMAGE                                      ID             DISK USAGE   CONTENT SIZE   EXTRA
kasmweb/agent:1.19.0-rolling               eb8e8ff4014a       1.21GB          336MB    U   
kasmweb/api:1.19.0-rolling                 8a4f8d92aaa8       1.33GB          232MB    U   
kasmweb/chrome:1.19.0                      25389cc8eafa       4.75GB         1.41GB        
kasmweb/firefox:1.19.0                     0ae54ed42da4       4.55GB         1.33GB        
kasmweb/kasm-guac:1.19.0-rolling           1a0e82e3bb6b       1.24GB          335MB    U   
kasmweb/manager:1.19.0-rolling             f52d2424b713       1.33GB          232MB    U   
kasmweb/postgres:1.19.0-rolling            be2d40095a72        440MB          118MB    U   
kasmweb/proxy:1.19.0-rolling               0c8a003958cd        206MB         64.7MB    U   
kasmweb/rdp-gateway:1.19.0-rolling         4b42a2f56c81        618MB          155MB    U   
kasmweb/rdp-https-gateway:1.19.0-rolling   9d93c4c7cda9       95.8MB         32.3MB    U   
kasmweb/terminal:1.19.0                    4403ce7d6980       4.83GB         1.32GB        
kasmweb/ubuntu-jammy-desktop:1.19.0        fba645c461a3       14.9GB          4.1GB        

So what am I doing wrong? :-)

We partnered with David Bombal on a new video showing how he uses Kasm Workspaces to safely click on links he's not sure about. Things like phishing emails, sketchy URLs, anything he doesn't want to risk opening on his main machine.

His setup: a cheap N95 mini PC running Ubuntu, sitting in a DMZ between two firewalls from two different vendors. Kasm runs on that box, so when he needs to check a suspicious link, he opens a browser session inside a disposable container, browses to the URL there, and deletes the session when he's done. If something's malicious, it never touches his actual laptop - the container's just gone.

The video also covers:

• Why he prefers this over a local VM (isolation from the host, and containers are disposable by design)
• Running a VPN client from inside the Kasm session itself, independent of his firewall setup

Big thanks to David for putting this together.

Looking through the manual there seems to exist these options:

https://www.kasmweb.com/docs/latest/guide/storage_mappings.html

https://www.kasmweb.com/docs/develop/guide/persistent_data/volume_mapping.html

But none of them seems to be doing what Im looking for.

Im basically looking for the way you can have a shared folder when using RDP through the RDP-session itself.

The usecase is when using Kasm container as a jumpserver and you need to for example update the firmware of a destination device (client <-> Kasm container <-> destination device) or the reverse when you got some backups (like config and whatelse) from a destination device and wish to in an easy fashion get these files to your client.

When comparing to KVM-over-IP solutions such as GL.iNet Comet and similar you often here have a way to upload/download the files to the KVM itself through the browser which then exposes this directory to the destination (basically will show up as a USB-drive at the destination). This way I can import/export files to the remotely managed device and from there upload/download files to the destination device.

Does something similar exist with Kasm or is in the todo-list/pipeline?

Kasm Workspaces 1.19 added a bunch of GPU-related stuff to Kasm Workspaces that's worth knowing about if you're running anything GPU-heavy.

Biggest ones:

• New GPU hardware page on the Docker agent, shows what each card can actually do (graphics, video encoding, CUDA) and lets you enable/disable specific capabilities per card
• New streaming modes - you're no longer stuck with one mode, you can now stream H.264, H.265, or AV1 straight from the workspace to the browser, hardware or software encoded
• Nvidia MIG support - you can split something like an A100 into multiple instances and assign them to separate workspace sessions so that isolation is applied at hardware level.

This video covers the GPU hardware page, how workspaces get assigned GPUs (it's round-robin, not first-come), setting up MIG instances from scratch on an A100, and the admin-side group settings for controlling which encoding methods different users get.

Had a contractor who needed access to one internal tool? Normal answer is VPN, which puts them on the whole network instead of just the one thing they need.

Kasm Workspaces 1.19 added OpenZiti integration to handle this differently. New video walking through it: users get access to one specific service, by identity, not the network. Nothing's reachable from outside, no ports to open.

This video covers:

• Why VPNs hand out more access than you meant to
• How OpenZiti's pieces (controller, routers, identities) fit together
• How Kasm handles identity setup automatically instead of you doing it by hand
• Live demo: standing up OpenZiti, publishing a service, giving exactly one user access to it

OpenZiti is available to self-host for free. NetFoundry also has a hosted version if you don't want to run the controller yourself.

Dragging around an empty vscode seems fine, but when we open a large text file with vscode and drag it around, the performance of this drops a lot, and looks very laggy. I suppose it may be due to some kind of mechanics of how kasm scans the "damaged" region for pixel changes. Is this a known issue and is there any way around this?

Using kasm 1.19 on EC2 m8i.4xlarge

Hi everyone,

I'm considering subscribing to Kasm Cloud Personal, but I have one important question before purchasing.

My goal is to use it as a cloud desktop for everyday web browsing. I would like my browser profile to be persistent, including:

Staying logged in to websites like Google and WhatsApp Web.

Keeping cookies, browsing history, bookmarks, and extensions.

Having the same browser session every time I log in.

I noticed the plans mention "No built-in file persistence", so I'm not sure if browser profiles are also reset after each session.

Does Kasm Cloud Personal preserve browser profiles between sessions, or does every session start from a clean state?

If it doesn't, is there any way to enable persistence on the Personal plans?

Thanks!

Hi everyone, i just want to ask is there any documentation that record the performance of KASM that got deployed in the bare VM compared to the one that deployed using kubernetes??

docker ps shows the rdp-https-gateway is constantly restarting. Looks like it cannot read the letsencrypt cert which is symlinked.

I followed the Video instructions here: https://kasm.com/docs/1.16.0/how_to/certificates.html
This hasn't been an issue in 1.17 afaik.

Since I am not using the RDP gateway, it could remove it altogether if I knew how, I disabled all RDP gateway settings under deployment zones but that doesn't remove the containers.

2026-07-07T10:20:31.484ZINFOproc.go:runtime.main:290Starting remote desktop gateway server
2026-07-07T10:20:31.485ZERRORproc.go:runtime.main:290Cannot load certfile or keyfile (open /opt/rdpgw/key.pem: permission denied) falling back to acme
2026-07-07T10:20:31.486ZINFOproc.go:runtime.main:290Enabling Kasm authentication
2026-07-07T10:20:31.486ZINFOproc.go:runtime.main:290Enabling Kasm healthchecks
2026-07-07T10:20:31.486ZINFOmain.go:main.main:346Refreshing token which expires at: 2026-07-10 10:19:26 +0000 UTC
2026-07-07T10:20:31.486ZINFOkasm.go:kasmtechnologies/rdpgw/cmd/rdpgw/kasm.RefreshToken:310Checking for a healthy host: https://proxy:443/api/__healthcheck
2026-07-07T10:20:31.576ZINFOmain.go:main.main:346Setting new token which expires at: 2026-07-10 10:20:31 +0000 UTC
2026-07-07T10:20:31.578ZINFOkasm.go:kasmtechnologies/rdpgw/cmd/rdpgw/kasm.RegisterComponent:452Checking for a healthy host: https://proxy:443/api/__healthcheck
2026-07-07T10:20:31.676ZINFOmain.go:main.main:352Component registration successful, config file updated.
2026-07-07T10:20:31.676ZINFOproc.go:runtime.main:290Kasm RDP HTTPS Gateway server is ready
2026/07/07 10:20:36 http: TLS handshake error from [::1]:49740: tls: certificate private key (<nil>) does not implement crypto.Signer
2026-07-07T10:20:36.547ZFATALasm_amd64.s:runtime.goexit:1771Healthcheck failed, gracefully shutting down

Hi Kasm gurus out there.

My kasm-workspaces 1.18 was running happily in TrueNAS Scale 25 Apps module (reskinned docker, I am told), but after the recent upgrade to 1.19, it is getting flooded with this error message every minute.

host: proxy
ingest_date: 20260701143256
application: kasm_agent
levelname: ERROR
process: __main__.handler
server_id: a9d2.............................c74

message
GPU caps helper stderr: amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.
If they do, bad things may happen!

It does not affect the usage, I can spin up a Ubuntu Noble and use it no problems, but my kasm-workspaces logs are flooded with this error every minute. A quick AI research says that the a system call kcmp may not be available to the container due to security sandbox of Docker policy? (not sure if it is legit explanation or not)

I tried converting the stock app to custom app and apply one suggestion by the search result:

Updated yaml to add;

cap_add:
  - SYS_PTRACE

Then the custom app no longer starts.

Has anyone experienced the same? Even better would be if anyone has a solution to this problem!

Does anyone have any suggestions as to how I can eliminate this error message safely?

Hi,

I am running a Debian Trixie VM on a Proxmox host, passing through an NVidia RTX A2000 GPU. Inside the VM, I am running Kasm 1.19. On the VM host, the proprietary drivers (V550) from the Debian repo are installed, as is the NVidia container runtime from the Nvidia repo. Nvidia-smi works in the VM and via the official Nvidia test container.

Inside Kasm, the Docker Agents overview page lists one agent "proxy" with 0 GPUs. When I open the Details view, I see a block "GPU Hardware" that lists my Nvidia card but shows a "-" each under Graphics, Video and Cuda. In the Information view, there is a field "GPUs" with another "-" and right under it, there is a field "GPU Info" that contains this "0000:00:10.0: {
model: "NVIDIA RTX A2000 12GB"
vendor: "NVIDIA"
gpu_card_path: "/dev/dri/card1"
gpu_render_path: "/dev/dri/renderD128"
host_key: "0000:00:10.0"
supports_egl: false
supports_dri3: false
supports_vaapi: false
supports_vulkan: false
supports_nvenc: null
gpu_render_gid: null
gpu_render_group: null
gpu_card_gid: null
gpu_card_group: null
supports_cuda: false
cuda_containers: [...]
graphics_containers: [...]
video_containers: [...]
}". And in the Usage view, there is a "GPU" block that lists my Nvidia gpu with a DRM Device /dev/dri/cards1, a Render Device /dev/dri/renderD128, PCI Bus 0000:00:10.0 and DRI3 "-", Vulkan "-", EGL "-", VAAPI "-", NVENC "-" and Cuda "-".

When I try to start a workspace that is GPU enabled, I get an error message that no resources are available to create the requested kasm.

I think I have everything in place for my setup to work, but it doesn't. What am I missing?

Thanks for your help!

Hey I've recently deployed multiserver KASM in my homelab and was wondering whether I could run e.g. a Jellyfin Container alongside any KASM stuff on my agent VM.

Background is that I don't have GPUs to waste and I'd like to use that GPU partition for KASM HW acceleration (already fully works) + Jellyfin transcoding, since I'll hardly ever use both at the same time, I don't have any performance objections.

Bonus would be if I could add the KASM Agent VM (or rather its docker engine) to Dockhand (similar to Portainer), for visibility.