On 03/14/2017 04:29 PM, Daniel P. Berrange wrote: > > I'm fuzzy about the issue faced with containers. Containers will usually > have a separate /dev that is populated by the container mgmt engine (whether > docker, libvirt, lxc or something else). That mgmt engine is responsible for > setting permissions of /dev/kvm in the container's /dev if the user asked for > /dev/kvm to be made available. udev should never run inside a container - it > is only supposed to run in host context. So any udev rules that manipulate > /dev/kvm permissions will only ever be used in host context and never have > any effect on containers. > > The bug listed above doesn't actually describe any real problem with > containers & /dev/kvm - my reading is that the bug is just thinking > about a hypothetical future problem, but since udev isn't involved > in containers' /dev mgmt, I don't think there's a bug that needs fixing > here. $user here. The problem was real, but I don't know how legitimate the need for change is. I opened the bug so that we could have a discussion about it. Basically as a user that wants to run libvirt inside a container I was facing issues (permission denied). I noticed randomly that if I had installed qemu on the host before I tried to run libvirt inside of a container everything was fine. If I started from a fresh system (no qemu ever installed on the host) and tried to run that same container, I could not do it. Cole Robinson helped me track down that it was a permissions issue on /dev/kvm itself. Then I found the permission fixup code in the qemu rpm, which led me to think it might be better to open up the permissions even if qemu is not installed so that containerized libvirt use cases could succeed without having to workaround it. To workaround the person starting the container would need to change perms on /dev/kvm or have the container do that itself before running libvirt. I'm just saying that if we put this "hack" in qemu, then it seems like we might as well have it outside of qemu so that the 'qemu is delivered by a container' use case can work. Dusty _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
