Docker Rootless - Troubles running container, specific issues with KVM & GPU passthrough

[K-J-VV]

I'm trying to have this run in a Docker Rootless instance but doesn't seem to be working well. Here is what's happening:

When I set both KVM=Y and GPU=Y, the error message is:

ERROR: KVM acceleration not available (no write access), this will cause a major loss of performance.

When I set KVM=N and GPU=Y the error message is:

ERROR: qemu-system-x86_64: egl: no drm render node available qemu-system-x86_64: egl: render node init failed

When both are set to N, the container does start and it looks like Windows is "beginning" but it just infinitely loads. I'm assuming it's incredibly slow because KVM and GPU are both not being used?

I did see an older issue suggesting to try setting BOOT_MODE=windows_plain , whether this is on or off results in the same. I've also tried Windows 11 vs 10 but same issue persists.

I'm also confident my GPU is able to passthrough to Docker and be used rootless as I have other containers (Ollama, etc.) using GPU passthrough. The problem I think that is occurring is issues with rootless docker controlling/accessing KVM/Qemu? The image below is the load screen of the closest to a running container I've beenable to achieve

[kroese]

Forget about the GPU acceleration.. This is not working yet because there are no drivers for it yet, and the only other way is via PCI passthrough, but its extremely complicated, even without rootless.. See #22

For KVM acceleration it might work with rootless if you add privileged: true to the compose file.

[K-J-VV]

@kroese Got it, completely disregarding GPU then at this time

Forgot to mention I have tried as privileged but receive the same error: ERROR: KVM acceleration not available (no write access), this will cause a major loss of performance.

I have also tried with/without the following, but same KVM error

security_opt: - seccomp:unconfined

[kroese]

Seems the /dev/kvm on your host does not have the right permissions. What does it print when you run kvm-ok on the host (see the FAQ). Also, what OS are you running?

[K-J-VV]

sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

KVM is working, I think the issue may be specifically with KVM access as a rootless docker (although user is in libvirt group)

[kroese]

I know from another project of mine that it has users which run it with rootless docker and did not experience any problem with KVM. So I am sure its possible, but there are so many different Linux distributions that it may be possible that on some distros the permissions for /dev/kvm are configured differently or something like that.

So on what OS is this?

[K-J-VV]

I think you're right, I just changed permissions and was able to run the container/install without problem

here were original permissions:

ls -alh /dev/kvm
crw-rw---- 1 root kvm 10, 232 Apr 10 20:00 /dev/kvm

I have to run sudo chown user /dev/kvm to get it working for my non-root user. I'm on Debian Bookworm if that helps. I'll have to do some more research to understand how changing ownership of /dev/kvm may affect other things? Not sure I like this as a 'fix' lol

[kroese]

Maybe you need to do it like in this issue:

moby/moby#40225 (comment)

Where he adds the docker user to the kvm group.

[K-J-VV]

That's what I assumed would work, and the user has been part of kvm group before trying to run the container (restarted server, logged out/logged back into ssh, etc). But it seems like the only way to have it work is by using chown. Which again, I don't like because I'm not sure how that will affect other things and also I have other users I'd like to be able to use kvm as well

Here are the user groups user cdrom floppy sudo audio dip video plugdev users kvm netdev libvirt libvirt-qemu

[kroese]

Okay.. Maybe instead of changing the owner, you can keep root as the owner, but do a chmod to change the default value from 660 to 777 for example.

I think the security implications would be pretty low. After all, if some unauthorized process gets access to /dev/kvm they will only be able to execute some virtualized instructions inside a sandbox, which doesnt provide access to your real system. But I am not 100 percent sure, so dont hold me to it haha

[K-J-VV]

I'll have to read and learn-up on this, I'd guess 777 will work I just don't find it elegant. Much rather have just adding users to kvm group work (as it should?), but this is a personal problem..

Love the fact this project exits! Great work and appreciate the responsiveness