Hi all. Perry, Scott, and I met yesterday to discuss some holes in the oVirt permission system. We know there are some use cases that aren't handled by the current three-permission setup, so we came up with the following which seems to handle just about everything. We'll have 4 permission levels that are hierarchical, meaning the top-level permission implies all lower levels and so on. Permission levels are attached to "pools", either hardware pools or VM resource pools, and they are inherited by subpools of those pools. For the moment we do not attach permission levels directly to VMs although we may do so in the future if it is necessary. Permission levels could be called: 1. "User Admin" or "Super Admin" 2. "Administrator" 3. "User" 4. "Monitor" or "View" Permission level 1 mainly implies the ability to grant permissions and quota to other users, along with all lower-level permissions. Permission level 2 implies the ability to create and delete hardware pools and virtual machine resource pools, and create, delete, and manipulate the objects in those pools (hosts, storage servers, quota, VMs, and so on). This includes the ability to create and delete VMs in a VM resource pool. Permission level 3 grants the ability to start/stop/suspend/resume/save/restore VMs in a virtual machine resource pool, along with accessing the console of a VM. Permission level 4 implies the ability to view objects in the oVirt hierarchy. We think this will address the lion's share of permission-related use cases. Comments encouraged. Take care, --Hugh