When two people try to use deploy chroots at the same time, each of them will reassign the ownership of /dev/kvm to be root:kvm, so that users in the kvm (like the automatically-created one) will be able to run kvm-accelerated virtual machines.
Unfortunately, different deploy chroots may have different group IDs for the kvm group, especially if they have different operating system version numbers. This means they start to play "tug-of-war" over the ownership; whichever one doesn't have the right ownership will fail to launch VMs, and when the deploy chroot is restarted to fix it, it takes away the right ownership from the other deploy chroot.
This also has the side concern that it may change access on the host to a group that it shouldn't be giving access to -- like a group used to isolate vulnerable system services. While this isn't much of a concern on RHOMBI, which doesn't run very many services, it could be a problem in other deployment situations.
The reason they need to have the same ownership is that each chroot has a bind mount of /dev/kvm. We should just mknod (or maybe even cp) the node into each chroot, which will allow each deploy chroot to set its own ownership appropriately for its own device.
When two people try to use deploy chroots at the same time, each of them will reassign the ownership of /dev/kvm to be root:kvm, so that users in the kvm (like the automatically-created one) will be able to run kvm-accelerated virtual machines.
Unfortunately, different deploy chroots may have different group IDs for the kvm group, especially if they have different operating system version numbers. This means they start to play "tug-of-war" over the ownership; whichever one doesn't have the right ownership will fail to launch VMs, and when the deploy chroot is restarted to fix it, it takes away the right ownership from the other deploy chroot.
This also has the side concern that it may change access on the host to a group that it shouldn't be giving access to -- like a group used to isolate vulnerable system services. While this isn't much of a concern on RHOMBI, which doesn't run very many services, it could be a problem in other deployment situations.
The reason they need to have the same ownership is that each chroot has a bind mount of /dev/kvm. We should just mknod (or maybe even cp) the node into each chroot, which will allow each deploy chroot to set its own ownership appropriately for its own device.